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Capitulo 1 

Liderar ou sangrar? 


Se voce vai investir seu dinheiro, muitas opijoes estao disponiveis. Voce pode investi- 
lo em uma poupan^a, apesar de que o rendimento possivelmente nao seja tao van- 
tajoso se comparado com a inflaijao. Ou voce pode investi-lo em titulos do governo. 
Novamente, voce pode nao ganhar tanto dinheiro, mas sao apostas seguras. 

Ou ainda, voce pode investir em uma pequena startup. Voce pode, por exemplo, 
investir algum dinheiro em troca de uma pequena parte na sociedade da empresa. Se 
a ideia da empresa for boa e ela puder executa-la, voce pode potencialmente ganhar 
bastante dinheiro. Por outro lado, nao e nem garantido que voce va recuperar seu 
investimento. 

Esse conceito nao e novo. Voce come^a a aprende-lo como uma crian^a brin- 
cando. Se eu correr por aqui, eu vou surpreender todo mundo e nao vou ser pego. 
Voce e lembrado disso com bastante frequencia no seu cotidiano. Voce passa pelo 
trade-off risco-recompensa quando esta atrasado para uma reuniao e precisa esco- 
lher o melhor caminho para o trabalho. Se o transito nao estiver ruim, eu posso 
chegar la 15 minutos mais rapido se eu for por esse caminho. Mas se tiver transito, 
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estou ferrado. 

O trade-off risco-recompensa e uma parte importante do processo de fazer esco- 
lhas intencionais sobre em quais tecnologias e domfnios investir. Quinze anos atras, 
uma escolha de baixo risco seria aprender a programar em COBOL. Claro, tambem 
havia tantos programadores COBOL com quern concorrer, que o salario medio nessa 
epoca ja nao era fenomenal. Voce podia facilmente encontrar trabalho, mas nao seria 
algo tao lucrativo. Baixo risco. Baixa recompensa. 

Por outro lado, se aquela epoca voce tivesse decidido investigar a nova linguagem 
de programa^ao da Sun Microsystems, o Java, durante um tempo talvez fosse dificil 
encontrar emprego em algum lugar que estivesse usando essa linguagem. Quern iria 
saber se alguem realmente faria algo em Java? 

Mas se voce estivesse de olho em como estava a industria naquela epoca, da 
forma como a Sun estava, voce poderia ter visto algo especial no Java. Poderia ter 
sentido que aquilo se tornaria grande. Investir naquela tecnologia logo no initio faria 
de voce um lider em uma grande e influente tecnologia. 

E claro, nesse caso voce teria se dado bem. E se tivesse jogado suas cartas cor- 
retamente, seu investimento em Java teria sido muito lucrativo. Alto risco. Alta re¬ 
compensa. 

Agora, imagine que tambem ha 15 anos voce tenha visto uma demonstra^ao do 
novo BeOS, da Be. Na epoca ele era incrivel. Ele foi construido para tirar vantagem 
de multiplos processadores. Suas capacidades de multimidia eram impressionantes. 
A plataforma fez bastante barulho na epoca e os especialistas sentiam que estava ali 
um novo concorrente fortissimo no mercado de sistemas operacionais. 

Com a nova plataforma, claro, viriam novas maneiras de programar, novas APIs, 
novos conceitos de interfaces com o usuario. Era muita coisa para se aprender, mas 
parecia valer bastante a pena. Voce poderia ter criado o primeiro cliente de FTP ou o 
primeiro gerenciador de informaijoes para o BeOS. Quando a Be lan^ou uma versao 
compativel com processadores Intel, rumores indicavam que a Apple a compraria a 
empresa para usar sua tecnologia na proxima gera^ao do sistema operacional Ma¬ 
cintosh. 

A Apple nao comprou a Be. E apos algum tempo, ficou claro que a Be nao iria 
conseguir nem sequer um mercado de nicho. O produto simplesmente nao pegou. 
Muitos desenvolvedores que dominaram programa^ao para o BeOS come^aram a 
perceber que aquele investimento nao se pagaria no longo prazo. Apos algum tempo, 
a Be foi comprada pela Palm e o sistema operacional foi descontinuado. BeOS era 
um investimento arriscado, porem atrativo, que nao deu retorno a longo prazo. Alto 
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Capitulo 1 . Liderar ou sangrar? 


risco. Nenhuma recompensa. 

Ate aqui, eu falei sobre a diferen^a entre escolher tecnologias que ainda sao re- 
centes e as que ja estao estabelecidas. Escolher uma tecnologia estavel e que ja esta 
em produ^ao em diversos sistemas e uma escolha mais segura, no entanto, com re¬ 
compensa potencialmente menor do que uma tecnologia que poucos conhecem e 
que ninguem sabe como colocar em produ^ao. Mas e as tecnologias que ja estao 
saindo de cena? Aquelas que ja estao apenas esperando para serem enterradas? 

Quern dara fim nessas tecnologias? Voce pode pensar nos ultimos poucos pro- 
gramadores que desenvolvem em RPG como sendo aqueles caras de cabelos grisa- 
lhos e contando as horas ate a aposentadoria, enquanto os j ovens desenvolvedores 
nunca ouviram falar de RPG. Eles estao todos aprendendo Java e .NET. E facil pensar 
que a carreira dos ultimos sobreviventes de uma velha e decadente tecnologia estao 
na mesma espiral da morte que a propria tecnologia. 

Mas sistemas antigos nao morrem simplesmente. Eles sao substituidos. Alem 
disso, na maioria dos casos, sistemas caseiros sao substituidos em estagios. Nesses 
estagios, o sistema antigo precisa conversar com o novo. Alguem precisa fazer o novo 
falar com o antigo e vice-versa. Usualmente, as crian^as rebeldes nao sabem (ou 
nao querem saber) como fazer o sistema antigo escutar. E nem os mais velhos pre- 
aposentadoria sabem como fazer as novidades conversarem com sua amada criatura. 

As duaspontas da curva de ado^ao devem provar serem lucrativas. 


Entao, ha um papel a ser preenchido pelos desenvolvedores: o asilo da tecno¬ 
logia. Ajudar antigos sistemas a morrer confortavelmente e com dignidade e algo 
que nao deve ser subestimado. E logico, a maioria das pessoas ira pular do barco 
antes que ele afunde, seja via aposentadoria ou indo para outra tecnologia. Sendo 
o ultimo que sobrou para manter os sistemas que ainda sao criticos, voce e o cara. 
E arriscado, ja que, uma vez que a tecnologia ja era, voce sera especialista em algo 
que nao existe. No entanto, se voce puder se mover rapido o suficiente, voce pode 
procurar a proxima gera^ao de sistemas que estao morrendo e come^ar novamente. 

A curva de ado<;ao tern altas nas duas pontas. Onde nessas curvas voce quer 
estar? 

Fa$a algo 
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1) Fai;a uma lista de tecnologias recentes, medias e antigas baseada no mercado 
atual. Mapeie-as em uma folha da esquerda para a direita. Na esquerda, colo- 
que as tecnologias recentes, e na direita, as que estao proximas do fim. Force a si 
mesmo para encontrar a maior quantidade possivel de tecnologias. Seja o mais 
granular possivel sobre onde as tecnologias estao quando comparadas umas com 
as outras. 

Quando voce tiver mapeado o maximo de tecnologias que conseguiu se lembrar, 
marque as tecnologias nas quais voce se considera forte. Entao, talvez em uma 
cor diferente, marque aquelas sobre as quais voce possui algum conhecimento, 
mas nao domina. Onde esta a maioria das tecnologias que voce marcou? Elas 
estao aglomeradas em alguma ponta? Estao espalhadas? Elas estao proximas as 
pontas em que voce se interessa? 
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Capitulo 2 

Oferta e demanda 


Quando a Web realmente come^ou a decolar, era possivel ganhar bastante dinheiro 
simplesmente criando paginas HTML para empresas. Toda empresa queria uma pa- 
gina web e relativamente poucas pessoas sabiam como faze-las. Empresas estavam 
dispostas a pagar bem para web designers “experientes”, o que naquela epoca signi- 
ficava dizer que conheciam o basico de HTML, cria^ao de links e estrutura de sites. 

Fazer HTMLs e muito simples. Dificil e fazer paginas que sejam visualmente 
bonitas, mas o basico e facil de atingir. Conforme as pessoas perceberam os valores 
cobrados por esses web designers, mais e mais pessoas come^aram a pegar livros 
de HTML e aprender a tecnologia por conta propria. O mercado estava quente, os 
salarios ou valores por hora eram atraentes, e como resposta, a oferta de especialistas 
em HTML come^ou a aumentar. 

Conforme o mercado foi inundado de web designers, o pessoal de web come^ou 
a ser classificado entre reais artistas, que dominavam a tecnologia e possuiam grande 
habilidade, e os praticos, que nao tinham a mesma qualidade e competencia dos 
reais artistas. Alem disso, a concorrencia acabou levando a queda dos pre^os. Como 
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um resultado dos prei;os mais baixos, mais empresas estavam dispostas a dar seu 
primeiro passo em dire^ao a presen^a na internet. Eles nao pagariam $5,000 por seu 
primeiro site, mas sim $500. 

Claro, algumas empresas ainda estavam dispostas a pagar bastante dinheiro por 
um site “fantastico”. E certamente os web designers ainda conseguiam cobrar valores 
“fantasticos”. 

Em um determinado momento, a inunda^ao de web designers de medio e baixo 
custo regrediu. Web designers menos talentosos foram substituidos por usuarios 
finais e outro pessoal de TI que nao necessariamente dominava HTML. Nesse ponto, 
a oferta, demanda, e o pre^o de desenvolvimento chegou a um equilibrio. 

Essa historia sobre a evolu^ao do web design mostra um modelo economico de 
que todos nos ja ouvimos falar, chamado oferta e demanda. Quando a maioria de 
nos pensa em oferta e demanda, achamos que tern a ver com o pre<;o com que algo 
pode e sera vendido. Se houver mais de um item a venda do que o numero de pessoas 
querendo comprar aquele produto, entao seu pre^o vai diminuir. Se houver mais 
pessoas querendo comprar o produto do que a quantidade de produtos disponiveis, 
o preCjX) ira aumentar, de forma que os compradores concorram entre si. 

Alem de prever o pre<;o de bens e servi^os, o modelo de oferta e demanda pode 
prever como as mudan^as de pre^o irao afetar os que querem comprar e vender os 
produtos e serviijos. Geralmente ha mais compradores para um produto barato do 
que para um mais caro. 

Voce nao pode competir em pre$o. Na verdade, voce nao consegue competir em prefo. 


Por que isso e importante para nos? A tendencia de fazer software offshore acaba 
de injetar uma grande oferta de pessoas de TI de baixo custo em nossa economia. 
Embora estejamos preocupados em perder empregos, o custo mais baixo por progra- 
mador na verdade aumentou a demanda. Ao mesmo tempo, conforme a demanda 
aumenta, os pre<pos diminuem. Concorrencia em produtos e services com alta de¬ 
manda acaba por movimentar tambem os pre^os. No mercado de empregos, isso 
significa salarios. Voce nao pode competir em pre<;o. Voce nao consegue. Entao, o 
que fazer? 

O mercado de desenvolvimento offshore injetou seus programadores de baixo 
custo em um conjunto relativamente pequeno de tecnologias. Programadores Java e 
.NET sao baratos e existem aos montes na India, junto dos DBAs Oracle. Tecnologias 
menos populares sao pouco adotadas pelas empresas de offshore. Durante a escolha 
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Capitulo 2 . Oferta e demanda 


de um conjunto de tecnologias para focar em sua carreira, voce deve entender os 
efeitos da oferta crescente e menores preijos. 

Como um desenvolvedor .NET, voce deve se encontrar concorrendo com mais 
dezenas de milhares de pessoas do que, por exemplo, um desenvolvedor Python. 
Isso resultaria no custo medio de um desenvolvedor .NET reduzindo significativa- 
mente, possivelmente aumentando a demanda (nesse caso, criando mais empregos 
em .NET). Com isso, voce encontraria emprego, mas que nao pagaria tao bem. A 
oferta de programadores Python deve ser bem menor que a de .NET para suportar 
a demanda. 

Se o mercado de trabalho em Python estivesse pagando valores mais altos por 
programador, as pessoas ficariam atraidas por oferecer seus services por esses valo¬ 
res, resultando em concorrencia, o que levaria os pre<;os para baixo novamente. 

E tudo uma questao de balanceamento. Mas uma coisa parece certa (por en- 
quanto). A India prove programadores para os mercados de TI que ja estao balance- 
ados. Voce nao encontra empresas de offshore indianas e famosas utilizando tecno¬ 
logias nao convencionais. Eles nao sao pioneiros. Eles geralmente nao se arriscam. 
Eles esperam o mercado balancear para entao entrarem nesse mercado com valores 
por programador significativamente mais baratos. 

Com base nessa observa^ao, voce deve escolher competir em segmentos do mer¬ 
cado em que ha menor demanda. Por mais contraintuitivo que possa parecer, se voce 
esta preocupado em perder seu emprego para o offshore, uma estrategia seria evitar 
os tipos de trabalho que as empresas de offshore estao fazendo. Elas estao fazendo 
trabalhos com alta demanda. Entao, focar em tecnologias de nicho e uma estrategia 
que, embora nao necessariamente torne a competi^ao menos feroz (ha menos em¬ 
pregos para ir atras), muda o foco da concorrencia de pre<;o para habilidade. E isso 
o que voce precisa. Voce nao pode competir em preijo, mas voce pode competir em 
habilidade. 

Alem disso, com o pre^o medio dos programadores de tecnologias mainstream 
em queda, a demanda ira crescer. Um aumento geral nessa demanda por programa¬ 
dores Java, por exemplo, pode resultar em mais empregos no seu pais, nao menos. 
Um aumento no mercado de offshore, que e barato, pode influenciar na demanda. 

Isso acontece na pratica. Para que o offshore funcione bem, muitas empresas 
percebem a necessidade de manter uma quantidade de desenvolvedores de alto nivel, 
que definam os padroes da empresa, garantam a qualidade e provenham lideran^a 
tecnologica. Um aumento na demanda por programadores Java iria naturalmente 
elevar demanda nessa categoria de trabalho. Os trabalhos mais baratos podem estar 
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indo para o offshore, mas ha mais trabalhos de alto nfvel, ou de elite, do que ha- 
via antes da epoca do offshore. Como vimos nos mercados de nicho, a competi^ao 
mudaria de preijo para habilidade. 

Explore mercados nao balanceados. 


A li^ao mais importante que podemos levar do modelo de oferta e demanda e 
que com o aumento da demanda vem o aumento da concorrencia de pre^o. Seguir 
esse caminho o levara a concorrer em pre^o com desenvolvedores offshore, pois suas 
habilidades irao se encaixar nos mercados balanceados em que o offshore atua. Para 
competir em tecnologias mainstream, voce tera que enfrentar um nfvel mais alto. 
Alternativamente, voce pode explorar mercados nao balanceados, aonde as empresas 
de offshore nao vao. Em ambos os casos e imprescindivel entender as formas que estao 
em jogo e ser habilidoso e agil o suficiente para reagir a elas. 

Fa$a algo 

1) Pesquise a demanda por habilidades tecnicas. Use sites de vagas de trabalho e 
carreiras para encontrar quais habilidades estao em alta e em baixa demanda. 
Ache os sites de empresas de offshore (oufale com funcionarios dessas empresas). 
Compare as habilidades usadas nessas empresas com a lista que tecnologias em 
alta demanda que voce fez. Anote as tecnologias as quais voce ve que ha uma boa 
demanda, mas que empresas de offshore nao usam. 

Fa^a uma compara^ao similar entre tecnologias recentes e as habilidades pedidas 
por empresas de offshore. Fique de olho em ambos os conjuntos de habilidades 
tecnicas que nao sao usadas pelas empresas de offshore. Quanto tempo levara 
para que elas preencham esse buraco? Esse tempo e a janela na qual ha um mer- 
cado nao balanceado. 
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Capitulo 3 

Escrever codigo nao e suficiente 


Nao e suficiente pensar em quais tecnologias voce vai investir. Afinal, a parte de tec- 
nologia e um bem, certo? Voce nao vai ser capaz de sentar e simplesmente dominar 
uma linguagem de programa^ao ou um sistema operacional, permitindo que as pes- 
soas de negocios cuidem da parte de negocios. Se tudo o que eles precisavam era de 
um robo de codigo, seria facil contratar alguem de outro pais para fazer esse traba- 
lho. Se voce quer permanecer relevante, vai ter que ir fundo no dominio do negocio 
dentro do qual voce esta. 

Na verdade, uma pessoa de software deve compreender um dominio nao apenas 
bem o suficiente para desenvolver software para ele, mas tambem para se tornar uma 
de suas referencias. Em uma empresa onde trabalhei, vi um excelente exemplo disso. 
A equipe de administra^ao de banco de dados consistia de pessoas que realmente nao 
estavam interessadas em tecnologia de banco de dados. Quando eu as encontrei pela 
primeira vez, foi um choque. Por que essas pessoas trabalham com tecnologia? Eu 
me perguntava. Em termos de habilidade tecnica, eles nao eram bons. Mas este time 
tinha algo especial. Sendo os guardioes e protetores de dados de nossa empresa, eles 
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conheciam o dominio do negocio melhor do que quase qualquer analista de negocios 
que tinhamos. Seus conhecimentos e compreensao do negocio os tornaram figuras 
importantes nesse mercado. Enquanto nos, geeks, estavamos olhando para eles com 
desdem, o “negocio” para o qual eles trabalhavam via um enorme valor neles. 

Voce deve pensar em sua experiencia de dominio do negocio como uma parte 
importante do seu repertorio. Se voce e um musico, quando adicionar algo ao seu 
repertorio, nao significa apenas que voce tocou a musica uma vez. Significa que voce 
realmente conhece a musica. A mesma teoria deve ser aplicada a sua experiencia de 
dominio. Por exemplo, depois de ter trabalhado em um projeto no setor de seguros 
de saude, isso nao garante que voce entenda a diferenc^a entre uma transa^ao HI- 
PAA 835 e uma HIPAA EDI 837. E esse tipo de conhecimento que diferencia dois 
desenvolvedores trabalhando nessa problema. 

Voce pode ser “apenas um programador”, mas ser capaz de falar com seus clien- 
tes do negocio na lingua de seu dominio de negocio e uma habilidade unica. Imagine 
o quanto a vida seria mais facil se todo mundo com que voce tivesse que trabalhar 
realmente entendesse como funciona desenvolvimento de software. Nao seria neces- 
sario explicar a eles por que e uma ma ideia devolver 30000 registros em uma unica 
pagina em uma aplica^ao web ou por que eles nao compartilham o endere^o para 
seu servidor de desenvolvimento. Esta e a forma como os seus clientes de negocios 
se sentem em rela^ao a voce: Imagine o quao mais facil seria trabalhar com esses 
programadores, se eles entendessem o que eu estava pedindo, sem que eu tivesse 
que explicar tudo de forma tao burra e tao detalhista! E, adivinhem? E a empresa 
que paga o seu salario. 

Assim como as tecnologias se destacam, dominios podem ser escolhidos da 
mesma forma. Java e .NET sao agora mainstream no desenvolvimento de software. 
Se voce aprender essas linguagens, podera concorrer a um emprego em uma das 
muitas empresas que utilizam estas tecnologias. O mesmo e verdade para os domi¬ 
nios. Ao escolher em qual industria trabalhar, voce deve ter o mesmo cuidado que 
teve ao decidir quais tecnologias dominar. 

Agora e hora de pensar nos dominios em que voce investe seu tempo. 


Alem da importancia que se deve dar ao escolher um dominio ao montar seu 
portfolio, a empresa e industria em que voce escolher trabalhar se tornam um inves- 
timento significativo em si proprio. Se voce ainda nao tiver parado para pensar em 
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quais dominios deveria investir, agora e a hora. Cada dia que passa e uma oportuni- 
dade perdida. Da mesma forma que deixar suas economias em uma conta poupan^a 
de baixo rendimento, enquanto e possivel conseguir taxas de juros mais altas, deixar 
o seu desenvolvimento em negocios parado e uma pessima escolha de investimento. 

Fa$a algo 

1) Agende um almo^o com um empresario. Converse sobre como eles trabalham. 
Durante a conversa, pergunte a si mesmo o que voce teria que mudar ou aprender 
se quisesse ter o trabalho dele. Pergunte sobre as especificidades do seu trabalho. 
Converse sobre como tecnologia os ajudam (ou atrapalham). Pense no seu tra¬ 
balho a partir da perspectiva deles. 

Fa<;a isso regularmente. 

Isso pode parecer uma ideia estranha ou desconfortavel. Tudo bem. Eu comecei 
a fazer isso ha muitos anos e isso fez uma grande diferen^a na forma como eu 
entendia e me relacionava com o negocio no qual eu estava trabalhando. Eu tam- 
bem me senti mais confortavel falando com os meus clientes, o que e um efeito 
colateral positivo. 

2) Pegue uma revista especializada na industria de sua empresa. Provavelmente voce 
nao tera nem sequer que compra-la. A maioria das empresas tern essas revistas 
espalhadas em algum lugar. Comece a le-la. Provavelmente voce nao ira entender 
tudo o que le, mas seja persistente. Fa<;a listas de perguntas que voce pode fazer a 
seus gerentes ou clientes. Mesmo que suas perguntas lhe pare^am estupidas, seus 
clientes vao perceber que voce esta tentando aprender. 

Procure sites que voce possa monitorar de forma regular. Tanto nos sites como 
nas revistas, preste aten^ao ao assunto das grandes noticias e dos artigos. Quais 
sao os problemas que a industria esta tentando resolver? Qual e o novo assunto 
dominante? Seja o que for, converse sobre isso com seus clientes. Pe^a para eles 
lhe explicarem e darem suas opinioes. Pense em como essas tendencias atuais 
afetarao sua empresa, sua area, sua equipe, e eventualmente, o seu trabalho. 
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Capitulo 4 

Seja o pior 


Pat Metheny, lendario guitarrista de jazz, costuma dar um conselho para jovens mu- 
sicos: “Sempre seja o pior cara da banda em que voce estiver”. 

Antes de iniciar minha carreira em TI, eu tocava jazz e saxofone profissional- 
mente. Como musico, eu tive a sorte de aprender esta li^ao bem cedo. Ser o pior 
cara da banda significa sempre tocar com pessoas que sao melhores do que voce. 

Seja o pior em qualquer grupo em que estiver. 


Agora, por que voce escolheria ser a pior pessoa em uma banda? “Isso nao e 
irritante?”, voce se pergunta. Sim, e extremamente irritante, no comedo. Como um 
jovem musico, eu me via em situates em que ficava tao obvio que eu era o pior cara 
da banda, que eu tinha certeza que iria ficar de fora. Eu apareceria para o show mas 
nem pegaria meu sax, com medo de ser expulso da apresenta^ao. Eu estava perto de 
pessoas as quais antes eu observava e em cujo nivel esperava tocar, as vezes como o 
instrumento principal. 
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Sem falhar (felizmente!), algo magico acontecia: eu me encaixava no grupo. E 
nao me destacava como uma estrela entre os outros musicos. Mas por outro lado, eu 
nao era, tambem, deixado de lado. Isto acontecia por duas razoes. A primeira e que 
eu nao era tao ruim quanto eu pensava. Vou falar disso depois. 

A razao mais interessante pela qual eu me encaixava com estes caras tao bons, 
alguns ate meus herois, e que minha musica se parecia com a deles. Eu achava que eu 
tinha algum tipo de super poder de me transformar em um genio simplesmente por 
estar ao lado de algum deles, mas na verdade, e algo bem menos interessante que isso. 
Era um comportamento instintivo, programado em mim. E o mesmo fenomeno que 
faz com que eu fale mais dificil, use um diferente vocabulario ou habitos gramaticais 
quando estou perto de pessoas que falam de forma diferente. Quando voltamos da 
India, apos viver um ano e meio por la, minha esposa, as vezes, me ouvia falando e 
morria de rir. “Voce ouviu o que voce disse?” — eu estava falando ingles indiano. 

Ser o pior cara da banda trouxe o mesmo comportamento em mim como um 
saxofonista. Naturalmente eu tocava como os outros. O que torna esse fenomeno 
realmente sem glamour e que quando eu tocava em cassinos e bares com bandas 
nao tao boas, eu tocava mal como eles. Alem disso, meio que naturalmente eu via 
os maus habitos das bandas sendo levados por mim para as noites nas quais eu nao 
tocava com eles. 

Com isso, eu aprendi que as pessoas podem melhorar ou piorar em habilidade, 
apenas levando em conta com quern elas estao trabalhando. E hear em um grupo 
por muito tempo pode impactar na capacidade da pessoa. 

As pessoas ao seu redor afetam a sua performance. Escolha bem seu grupo. 


Mais tarde, conforme eu me mudei para a industria de tecnologia, percebi que o 
habito de procurar os melhores musicos era natural para mim como um programa- 
dor. Talvez inconscientemente eu procurei trabalhar com as melhores pessoas de TI. 
E, nao surpreendentemente, essa li^ao e verdade. Ser o pior cara (ou garota, e claro) 
na equipe tern o mesmo efeito de ser o pior cara da banda. Voce acha que e inex- 
plicavelmente mais inteligente. Voce pode ate mesmo falar e escrever de forma mais 
inteligente. Seus codigos ficam mais elegantes e voce acredita ser capaz de resolver 
problemas dificeis com solu^oes cada vez mais criativas. 

Vamos voltar para a primeira razao pela qual eu fui capaz de me integrar a es- 
sas bandas melhor do que eu esperava. Eu realmente nao era tao ruim quanto eu 
pensava. Na musica, e muito facil medir se os outros musicos pensam que voce e 
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Capitulo 4. Seja o pior 


bom. Se voce e bom, eles o convidam para tocar com eles novamente. Se voce nao 
for bom, eles o evitam. E uma medida muito mais confiavel do que apenas perguntar 
o que eles pensam, porque bons musicos nao gostam de tocar com musicos ruins. 
Para minha surpresa, eu percebi que, em muitos desses casos, eu era telefonado por 
um ou mais desses musicos superiores para algum trabalho adicional ou ate mesmo 
para come^ar bandas com eles. 

Tentar ser o pior faz com que voce pare de se vender por tao pouco. Voce pode 
pertencer a banda A, mas sempre se coloca na banda B, pois esta com medo. Re- 
conhecer abertamente que voce nao e o melhor tira o medo de voce ser descoberto 
da forma que voce nao gostaria. Na verdade, mesmo quando voce tentar ser o pior, 
voce nao sera. 

Fa$a algo 

1) Encontre uma situa^ao para voce ser o pior. Voce pode nao se dar ao luxo de 
mudar de equipe ou ate mesmo de empresa so porque quer trabalhar com pessoas 
melhores. Em vez disso, encontre um projeto para trabalhar como voluntario em 
que voce possa trabalhar com outros desenvolvedores, que irao torna-lo melhor 
por osmose. Veja se ha encontros de grupos de desenvolvedores em sua cidade 
e participe dessas reunioes. Desenvolvedores estao frequentemente procurando 
por projetos para ocupar seu tempo livre, praticar novas tecnicas e aprimorar suas 
habilidades. 

Se nao ha uma comunidade ativa perto de voce, use a internet. Escolha um pro¬ 
jeto open source de que voce goste e cujos desenvolvedores parecem estar em um 
nivel acima do seu. Va ate a lista de tarefas do projeto ou o historico da lista de 
discussao, escolha uma funcionalidade ou uma corre^ao de bug importante e es- 
creva o codigo! Imite o estilo de codigo do projeto. Fa^a disso um jogo. Fa<;a o 
seu codigo de forma que ele seja indistinguivel do restante do projeto, de modo 
que ate mesmo os desenvolvedores originais nao saibam quern escreveu. Entao, 
quando voce estiver satisfeito com o seu trabalho, submeta suas modificacjoes. Se 
for bom, vai ser aceito no projeto. Comece de novo e fa^a novamente. Se voce 
tomou decisoes das quais os desenvolvedores do projeto discordam, pegue ofeed¬ 
back deles, use-o para melhorar seu codigo e envie novamente as modifica^oes. 
Se eles modificarem seu codigo, tome nota das altera^oes que fizeram. Em seu 
proximo patch, tente fazer com que ele seja aceito com menos retrabalho. Even- 
tualmente, voce vai perceber que ira se tornar alguem de confiancja da equipe do 
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projeto. Voce vai se surpreender com o que se pode aprender a partir de um con- 
junto remoto de desenvolvedores seniores, mesmo se voce nunca teve a chance 
de ouvir suas vozes. 
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Capitulo 5 

Invista em sua inteligencia 


Quando escolher em que focar, pode ser tentador simplesmente olhar para as tec- 
nologias que geram mais empregos e concentrar-se nelas. Java e grande. .NET e 
grande. Aprender Java tem um efeito simples, transitivo: se eu sei Java, eu posso me 
candidatar, e possivelmente, conseguir um trabalho onde vou escrever codigo Java. 

Usando essa logica, seria insensato escolher investir em um nicho de tecnologia, 
especialmente se voce nao tem inten^ao de tentar explora-lo. 

O TIOBE, http://www.tiobe.com, usa os sites de busca da internet para identi- 
ficar a popularidade de linguagens de programa^ao, com base em pessoas falando 
sobre as linguagens. Segundo o TIOBE, “Os numeros sao baseados na disponibili- 
dade mundial de engenheiros qualificados, cursos e fornecedores”. Definitivamente 
nao e uma medida cientifica de popularidade, mas nao deixa de ser um bom indica- 
dor. 

No momento da escrita desse livro, a linguagem mais popular e o Java, seguido 
por C. C# esta em um respeitavel sexto lugar, mas com uma trajetoria levemente na 
ascendente. ABAP esta em decimo setimo lugar e esta caindo lentamente. Ruby, que 
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e a minha linguagem favorita — na qual eu iaqo praticamente todo o meu trabalho 
serio e aquele para o qual eu co-organizo uma conferencia internacional a cada ano 
— esta em decimo primeiro lugar. E no momento em que a primeira edi^ao deste 
livro foi publicada, ela nao ficou nem entre os top vinte. Ficou abaixo de ABAP! 

Por que Ruby? Eu estava louco ou fui burro? Deve ser um dos dois, certo? 

Em seu trabalho chamado “Grandes Hackers” — http://paulgraham.com/gh. 
html, Paul Graham deixou a comunidade de desenvolvedores irritadlssima com a 
afirmaijao de que os programadores Java nao eram tao espertos quanto quern pro- 
gramava em Python. Ele deixou bravo um monte de programadores Java burros (eu 
disse isso?), fazendo com que varios deles escrevessem respostas a ele em seus sites. 
A rea^ao violenta indica que ele atingiu algo. Eu estava na plateia quando seu tra¬ 
balho foi apresentado pela primeira vez, na forma de um discurso. Ele causou um 
flashback em mim. 

Eu estava em uma viagem de recrutamento na India, no meio de centenas de 
candidatos para dezenas de vagas, e a equipe de entrevistadores estava cansada e 
ficando sem tempo por conta do baixo indice de entrevistas bem sucedidas, que re- 
sultassem em contrata^oes. Com dores de cabe<;a e olhos vermelhos, fizemos uma 
reuniao tarde da noite para discutir uma mudamja estrategica na forma como iria- 
mos abordar os candidatos. Nos tinhamos que otimizar o processo para que pudes- 
semos entrevistar mais pessoas ou de alguma forma entrevistar pessoas melhores (ou 
ambos). Com o pouco que restava da minha voz depois de doze horas seguidas de 
tentar arrancar respostas de programadores mudos, eu pedi para adicionar Smalltalk 
para a lista de palavras-chave que nossos headhunters estavam usando para procurar 
no banco de dados de curriculos. “Mas ninguem sabe Smalltalk na India”, gritou o 
diretor de recursos humanos. Esse foi o meu ponto. Ninguem sabia, e programar 
em Smalltalk era uma experiencia diferente de programar em Java. A mudan^a da 
experiencia daria aos candidatos um nivel diferente de expectativas, e a natureza di- 
namica de Smalltalk levaria a uma outra maneira com a qual um programador Java 
iria abordar um problema. Minha esperamja era que esses fatores encorajassem um 
nivel de maturidade tecnica que eu nao tinha visto dentre os candidatos que eu co- 
nhecia ate entao. 

A adi<;ao de Smalltalk para a lista de requisitos rendeu um grupo de candidatos 
que era pequeno se comparado com nossa lista anterior. Essas pessoas eram diaman- 
tes brutos. Elas realmente aprenderam programa<;ao orientada a objetos. Estavam 
cientes de que o Java nao era a loucura idealista como as vezes era pintada. Mui- 
tos deles amavam programar! "Onde voce esteve nas ultimas duas semanas?”, nos 
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Capitulo 5. Invista em sua inteligencia 


pensavamos. 

Infelizmente, a nossa capacidade de atrair esses desenvolvedores, com os salarios 
que eramos capazes de pagar, era limitada. Eles ditavam o tom, e a maioria deles pre- 
feriu ficar onde estava ou continuou procurando um novo emprego. Apesar de nao 
conseguirmos recrutar muitos deles, aprendemos uma liqao valiosa de recrutamento: 
nos estavamos mais propensos a fazer propostas para candidatos com experiencias 
diversas (e ate mesmo pouco ortodoxas) do que para aqueles cuja experiencia era 
homogenea. Minha explica^ao e que, ou as pessoas boas buscam a diversidade, pois 
elas amam aprender coisas novas, ou ser tornado em experiencias e ambientes mais 
exoticos criava programadores mais maduros e preparados. Eu acredito que seja um 
pouco dos dois, mas, independentemente do motivo pelo qual ele funciona, a gente 
descobriu que isso funciona. Eu continuo usando esta tecnica quando procure de¬ 
senvolvedores. 

Entao, ao inves de tentar simplesmente aparecer na minha frente quando eu esti- 
ver a procura de alguem para contratar, por que voce nao vai investir em tecnologias 
em que voce raramente tera a chance de ser pago para trabalhar? 

Para mim, como um gerente de contrata^ao, a primeira razao e que isso mostra 
que voce esta interessado. Se eu sei que voce aprendeu alguma coisa por causa do 
autodesenvolvimento e (melhor ainda) pura diversao, eu sei que voce esta animado 
e motivado sobre a sua profissao. Fico muito irritado quando pergunto as pessoas se 
elas ja viram ou usaram algumas tecnologias nao tradicionais e OU90 como resposta: 
“nao me deram a oportunidade de trabalhar com isso”. Nao lhe deram oportunidade? 
Pra mim tambem nao! Eu fiz a oportunidade para aprender. 

Nao lhe deram a oportunidade...? Fa$a a oportunidade! 


Mais importante do que retratar a percep^ao de que se esta devidamente moti¬ 
vado e engajado em sua area e que a exposi^ao a essas tecnologias e metodologias 
nao tradicionais lhe traz mais profundidade e o torna melhor, mais inteligente e mais 
criativo. 

Se essa nao e uma razao suficientemente boa, entao provavelmente voce esta na 
profissao errada. 

Fa9a algo 
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1) Aprenda uma nova linguagem de programa^ao. Mas nao va de Java para C# ou 
de C para C++. Aprenda uma nova linguagem que o fa<^a pensar de uma maneira 
diferente. Se voce e um programador Java ou C#, tente aprender uma linguagem 
como Smalltalk ou Ruby, que nao usem tipagem forte e estatica. Ou, se esta pro- 
gramando orientado a objetos por bastante tempo, tente uma linguagem funcio- 
nal como Haskell ou Scheme. Nao precisa se tornar um especialista. Fa^a codigo 
o suficiente para que voce realmente sinta a diferenc^a de programar no novo am- 
biente. Se ela nao soar estranha o suficiente, ou voce escolheu a linguagem errada 
ou voce esta aplicando sua velha forma de pensar na nova linguagem. Pe<;a para 
desenvolvedores mais experientes reverem o seu codigo e fazerem sugestoes que 
o tornem idiomaticamente mais correto. 
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Capitulo 6 

Nao escute seus pais 


Em nossa cultura, se existe algo que e sagrado, provavelmente sao os conselhos dados 
por nossos pais. E visto como um dever da crian^a segui-los religiosamente. Livros, 
filmes e historias de televisao formam um conjunto de ideias na cabe^a de nossos 
pais. Mas para nossas carreiras no mercado de trabalho, esta ideia e errada. 

Seus pais preferem que voce esteja estavel ao inves de conseguir uma carreira 
notavel ao custo de correr grande risco pessoal. Mais do que quaisquer outras pes- 
soas, eles vao lhe dar conselhos influenciados pelo medo. Conselhos influenciados 
pelo medo tendem ao nao perder. Mas pensar em nao perder nao e o caminho para 
ganhar! Vencedores assumem riscos. Eles pensam sobre aonde eles querem ir, nao 
onde o resto das coisas estao. Planejamento de carreira guiado pelo medo provavel¬ 
mente o levara a algum cubiculo para o resto de sua vida, em vez de ao caminho para 
a grandeza. Claro, e seguro, mas nao e divertido. 

Para as gera^oes anteriores, diversao nao era fator decisivo quando o assunto era 
opcoes de carreira. Empregos nao deveriam ser divertidos. Eles deveriam trazer co- 
mida pra casa. Diversao e o que voce faz nos seus dias de folga. Diversao acontece 
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nas noites e fins de semana. Mas se o seu trabalho nao e divertido, como temos perce- 
bido, voce nao o faz bem. As coisas nao sao diferentes agora, mas nossa compreensao 
cultural do que significa trabalhar mudou para melhor. Mais pessoas entendem que 
a paixao leva a excelencia. E sem diversao, nao e provavel que haja qualquer paixao 
em um trabalho. 

Outro fator de tomada de decisao sobre carreira, que provavelmente nao vai de 
encontro com o pensamento dos seus pais, e que nao ha problema em mudar de 
emprego (na verdade, muitas vezes e preferfvel). Um profissional de software expe- 
riente ja viu o mercado por diferentes angulos: desenvolvimento de produto, suporte 
de TI, desenvolvimento de sistemas internos e trabalho para o governo. Quanto mais 
dominios e arquiteturas tecnicas voce ja tenha visto e trabalhado, mais esta prepa- 
rado para tomar as decisoes corretas em projetos mais desafiadores. Ficar em uma 
unica empresa, trabalhando para subir na hierarquia, e um ambiente limitador para 
crescer como um desenvolvedor. Ja foi o tempo em que as pessoas come^avam sua 
carreira em uma empresa e ficavam la mesmo ate se aposentar. Este tipo de compor- 
tamento costumava ser sinal de dedica^ao. Agora e uma responsabilidade. Se voce 
so trabalhou em um lugar e viu aquele conjunto de sistemas, muitos gerentes (inte- 
ligentes) podem ver isso como um ponto negativo contra voce quando for decidir 
se deve contrata-lo. Eu pessoalmente prefiro contratar alguem que tenha vivenciado 
diversas situates de sucessos e fracassos em ambientes diferentes do que alguem 
que conhece apenas um jeito de fazer as coisas. 

Ha muitos anos, eu percebi que a minha propria carreira tinha sido muito in- 
fluenciada pelos valores profissionais dos meus pais e sua gera^ao. Eu trabalhei em 
uma das maiores e mais estaveis empresas do mundo e estava crescendo em um ritmo 
lento e constante. Mas eu estava estagnando. Eu ficava me dizendo que eu nao es¬ 
tava catando migalhas, baseando-me no fato de que a empresa era tao grande que eu 
poderia executar diferentes tarefas em uma aparente infinidade de lugares. Mas no 
final, eu ficava no mesmo lugar fazendo o mesmo tipo de trabalho. 

Eu me lembro de conversar com um amigo sobre sair da empresa, e ele disse: “E 
o seu destino trabalhar em grandes empresas para o resto da sua vida?” Claro que 
nao! Entao, eu rapidamente encontrei outro emprego e sai. 

Este movimento marcou o infcio de um salto no meu sucesso na industria de 
software. Eu vi novos dominios, trabalhei em problemas mais dificeis, e fui recom- 
pensado como nunca havia sido. Algumas vezes chegava ate a ser assustador, mas 
quando eu decidi ser menos influenciado pelo medo e menos conservador nas deci¬ 
soes sobre minha carreira, ela acabou mudando e para melhor. 
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Capitulo 6. Nao escute seus pais 


Assuma riscos em sua carreira. Nao deixe o medo o consumir. E se voce nao 
estiver se divertindo, voce nao vai ser excelente. 

Como eu abri mao de 300 mil dolares na Microsoft para trabalhar full 
time no Github 

Por Tom Preston Werner 

Em 2007 eu estava sentado sozinho em uma mesa no Zeke Sports Bar and Grill 
na 3rd Street, em San Francisco. Eu normalmente nao vou a bares de esportes, e 
muito menos a um bar de esportes em SOMA, mas aquela quinta-feira foi uma noite 
"I Can Has Ruby”. Naquela epoca, eu acho que "I can has tambem foi um apelido 
razoavel para dar a praticamente qualquer coisa. ICHR era um encontro de hackers 
Ruby que geralmente mergulhavam em sessoes de fim de noite bebendo. Normal¬ 
mente as noites passavam, como a minha ressaca na manha seguinte, mas esta noite 
foi diferente. Esta foi a noite em que nasceu o GitHub. 

Eu acho que estava sentado na mesa sozinho, porque tinha acabado de pedir 
um Fat Tire e precisava dar uma parada na socializa^ao que estava acontecendo nas 
mesas longas e mal iluminadas do bar. No quinto ou sexto gole, Chris Wanstrath 
entrou, eu nao sei dizer se na epoca Chris e eu eramos amigos. Nos nos encontra- 
mos em meetups Ruby e conferences, mas apenas casualmente, com um mutuo “Ei, 
eu acho seu codigo impressionante”. Eu nao sei o que me fez fazer isso, mas eu fiz 
um sinal para ele e disse: “Cara, olha isso”. Cerca de uma semana antes, eu tinha co- 
me^ado a trabalhar em um projeto chamado Grit, que permitia acessar repositories 
Git atraves de codigo Ruby de forma orientada a objetos. Chris era um dos poucos 
rubistas na epoca que estava come^ando a levar Git a serio. Ele se sentou e eu co- 
mecei a mostrar o que eu tinha. Nao era muito, mas foi o suficiente para ver que 
tinha despertado algo em Chris. Percebendo isso, lancei um site meia-boca que fun- 
cionava como hub para programadores que queriam compartilhar seus repositories 
Git. Eu ate tinha um nome: GitHub. Posso estar parafraseando, mas sua resposta foi 
um enfatico “Estou dentro! Vamos fazer isso!” 

Na noite da proxima sexta-feira, 19 de outubro de 2007, as 22:24, Chris fez o 
primeiro commit para o repositorio do GitHub, marcando o inicio de nossa joint 
venture. 

Ate entao, nao havia nenhum acordo sobre como as coisas iriam funcionar. Era¬ 
mos apenas dois caras que decidiram hackear juntos em algo que parecia legal. 

Lembra daqueles minutos incriveis do Karate Kid em que Daniel esta treinando 
para se tornar um especialista em artes marciais? Lembra da musica? Bern, voce 
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deveria ouvir, porque estou prestes a lhe contar uma historia. A musica e You are the 
best do Joe Esposito. 

Pelos os proximos tres meses, Chris e eu passamos horas planejando e codifi- 
cando o GitHub. Eu continuei com o Grit e desenhei a interface do usuario. Chris 
construiu a app Rails. Nos nos encontravamos todos os sabados para tomar deci- 
soes de design e tentar pensar no nosso piano de pre^os. Eu me lembro de um dia 
muito chuvoso em que conversamos por umas boas duas horas sobre as diferentes 
estrategias de pre^os dos melhores egg rolls vietnamitas da cidade. Fizemos tudo 
isso mantendo nossos compromissos. Eu, por exemplo, trabalhava em tempo inte¬ 
gral na Powerset como desenvolvedor de ferramentas para o Ranking e a equipe da 
Relevance. 

Em meados de Janeiro, apos tres meses de noites e finais de semana, lan^amos 
um beta privado e enviamos convites para nossos amigos. Em meados de fevereiro, 
PJ Hyett se juntou a nos. Lan^amos o site ao publico em 10 de abril. Nao convidamos 
o TechCrunch. Neste ponto, nos eramos apenas tres caras de 20 e poucos anos sem 
um centavo sequer de investimento externo. 

Eu ainda estava trabalhando em tempo integral na Powerset em 1 de julho de 
2008, quando soubemos que ela tinha acabado de ser adquirida pela Microsoft por 
cerca de US$ 100 milhoes. Um timing interessante. Com a aquisiijao, eu estava a ca- 
minho de ser confrontado com uma escolha muito mais cedo do que eu imaginava. 
Eu poderia me tornar um funcionario da Microsoft ou sair e ir cuidar do GitHub 
em tempo integral. Aos 29 anos de idade, eu era o mais velho dos tres GitHubbers 
e tinha acumulado uma quantidade proporcionalmente maior de dividas e despesas 
mensais. Eu estava acostumado com meu estilo de vida de seis digitos. Para confun- 
dir ainda mais, minha esposa, Theresa, estava para voltar do seu PhD, na Costa Rica. 
Logo eu iria voltar a ser um homem casado. 

Para tornar a decisao ainda mais dificil, a oferta de emprego da Microsoft foi ten- 
tadora. Salario, mais 300000 dolares em tres anos. Isso e dinheiro o suficiente para 
fazer qualquer pessoa pensar duas vezes sobre qualquer coisa. Entao, fui confron¬ 
tado com isso: um trabalho seguro na Microsoft e com muito dinheiro garantido ou 
um trabalho arriscado, com quantidades desconhecidas de dinheiro, como empresa- 
rio. Eu sabia que as coisas com os outros Githubbers ficariam tensas se eu nao saisse 
da Powerset. Por terem guardado algum dinheiro e se tornado freelancers ha algum 
tempo, ambos tinham come^ado a se dedicar em tempo integral no GitHub. Era 
hora de “fazer ou morrer”. Era escolher o GitHub e investir nele ou fazer a escolha 
segura e desistir do GitHub para fazer dinheiro na Microsoft. 
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Capitulo 6. Nao escute seus pais 


Se voce quer uma receita para uma pessima noite de sono, eu posso lhe dar. Adi- 
cione uma peda^o de “O que minha mulher acha?” com 3.000 peda^os de Benjamin 
Franklin, misture com uma “cerveja a hora que voce bem entender” e adicione uma 
cobertura de chance de independence financeira. 

Eu me tornei muito bom em chegar nos meus chefes e dar a ma noticia de que eu 
estava deixando a empresa para ir fazer alguma coisa mais legal. Eu dei a noticia para 
meu chefe na Powerset na data limite de responder a proposta. Eu disse que estava 
saindo para ir trabalhar em tempo integral no GitHub. Como qualquer grande chefe, 
ele estava chateado, mas entendeu. Ele nao tentou me seduzir com um bonus maior 
ou qualquer coisa do tipo. Acho que no fundo ele sabia que eu ia sair. Talvez eu tenha 
ate recebido mais incentivo para bear do que os outros, por conta do risco. E vou lhe 
dizer, aqueles gerentes da Microsoft eram persistentes. Eles tern bonus de reten^ao 
como uma ciencia — bem, exceto quando voce tern um empreendedor no conjunto, 
a singularidade do mundo dos negocios. Tudo e desequilibrado quando voce tern 
um deles por perto. 

No final, assim como Indiana Jones nunca poderia recusar a oportunidade para 
procurar o Santo Graal, eu tambem nao poderia perder a chance de trabalhar para 
mim mesmo em algo que eu realmente amo, nao importa o quao segura outra op^ao 
fosse. Quando eu estiver velho e morrendo, eu pretendo olhar para tras em minha 
vida e dizer: “Uau, que aventura”, nao “Uau, me senti seguro.” 

Tom Preston-Werner e co-fundador do GitHub. 

Fa$a algo 

1) Quais sao seus maiores medos com rela^ao a sua carreira? Pense sobre as ultimas 
decisoes de carreira que voce tomou. Nao precisam ser grandes decisoes (afinal, 
se voce esta fazendo escolhas influenciadas por medo, suas decisoes provavel- 
mente nao serao grandes). Por exemplo, pode ser se voce aceitou alguma tarefa 
especial, ou se candidatou para uma promo^ao. Fai;a uma lista dessas escolhas, 
e para cada uma, obrigue-se a fazer uma avalia^ao honesta: o quanto dessa sua 
decisao foi conduzida pelo medo? O que voce teria feito se o medo nao o tivesse 
influenciado? Se a decisao foi de fato influenciada pela medo, como voce pode 
reverte-la ou encontrar uma oportunidade similar, em que possa tomar a decisao 
com menos medo? 
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Capitulo 7 

Seja generalista 


Por pelo menos algumas decadas, gerentes e donos de empresas desesperados tem 
fingido que o desenvolvimento de software e um processo fabril. Especifica^oes de 
requisitos sao criadas e os arquitetos as transformam em algo de nivel tecnico. De¬ 
signers completam a arquitetura com a documenta^ao detalhada do projeto, que e 
entregue para programadores robo, que com uma mao seguram um livro ruim e com 
a outra escrevem codigo. Por fim, um investigador recebe o codigo completo, que 
nao ganha o selo de aprova^ao a menos que cumpra as especifica^oes originais. 

Nao e nenhuma surpresa que os gestores queiram que o desenvolvimento de 
software seja como uma fabrica. Eles “entendem” como fazer fabricas funcionarem. 
Temos decadas de experiencia em como construir objetos fisicos eficientemente. As- 
sim, aplicando o que aprendemos de manufatura, devemos ser capazes de otimizar o 
processo de desenvolvimento de software para como qualquer outra industria fun- 
ciona. 

Na tao falada fabrica de software, os funcionarios sao especialistas. Eles se sen- 
tam em seu lugar na linha de montagem, combinando componentes Java ou apa- 
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rando arestas de um aplicativo Visual Basic. O investigador e um testador. Os com- 
ponentes vao passando e sao testados e carimbados da mesma forma todo dia. De¬ 
signers J2EE desenham aplica^oes J2EE. Programadores C++ programam em C++. 
O mundo e muito limpo e organizado. 

Infelizmente, a analogia da fabrica nao funciona. Software e no minimo tao ma- 
leavel como os requisitos de software. As coisas mudam no negocio, e os empresarios 
sabem que o software e soft e pode ser alterado para atender a essas mudan^as. Isso 
significa que arquitetura, design, codigo e os testes devem todos ser criados e revisa- 
dos de uma forma mais agil do que os processos de fabrica^ao mais enxutos podem 
proporcionar. 

Neste tipo de ambiente de mudan^as rapidas, o flexivel ira sobressair. Quando ha 
pressao, um empresario inteligente vai ate um profissional de software que consiga 
resolver o problema. Entao, como voce se torna a pessoa cujo nome e lembrado 
quando eles estao a procura de um super-heroi para salvar o dia? A chave e ser 
capaz de resolver os problemas que possam surgir. 

Quais sao esses problemas? E isso mesmo: voce nao sabe. Nem eu. O que eu 
sei e que ha problemas dos mais diversos, como de implanta^ao, falhas de projeto 
criticos que precisam ser resolvidos e rapidamente reimplementados, integra^ao de 
sistemas heterogeneos e gera^ao de relatorios. Diante de um conjunto de problemas 
tao diversos como este, aquele investigador ficaria rapidamente para tras. 

O rotulo de “conhece um pouco de tudo, mas tudo de nada” e normalmente pe- 
jorativo, o que implica que o rotulado nao tern o foco para realmente mergulhar em 
um assunto e domina-lo. Mas, quando sua loja online esta fora do ar e voce esta 
perdendo centenas de vendas conforme o tempo passa, e o “conhece um pouco de 
tudo” que nao so sabe como funciona o codigo do aplicativo, mas tambem pode fazer 
debug dos processos no servidor web rodando em UNIX, analisar a configura^ao do 
seu banco de dados para possiveis gargalos de performance, e verificar a configura- 
9ao de seu roteador de rede para encontrar problemas dificeis. E, mais importante, 
depois de encontrar o problema, o “conhece um pouco de tudo” pode rapidamente 
tomar decisoes de arquitetura e de design, implementar corre^oes de codigo, e im- 
plantar uma correijao para o sistema em produ^ao. Neste cenario, a ideia de fabrica 
parece bem antiquada na melhor das hipoteses e terrivelmente falha na pior. 

Outro ponto em que a fabrica de software nao funciona e que, em contraste com 
uma linha de montagem em que o trabalho continua vindo em um fluxo constante, 
projetos de software sao geralmente ciclicos. Nao so o fluxo dos projetos sao ciclicos, 
mas o trabalho dentro de um projeto tambem e. Um programador fica la sentado na 
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cadeira enquanto os requisites estao sendo especificados, arquitetados e projetados, 
ou o programador trabalha ao mesmo tempo em varios projetos. O problema com 
os programadores multitarefa e que, apesar das interludes da fabrica de software, 
quando o bicho pega, os programadores se baseiam bastante no contexto e na expe¬ 
rience para concluir seus trabalhos. Requisitos, arquitetura e documentos de design 
podem ser um comedo, mas no final, se os programadores nao entenderem o que o 
sistema deve fazer, eles nao serao capazes de implementa-lo bem. 

Claro que aqui eu nao estou pegando no pe so de programadores. O mesmo 
e verdade em quase todas os pontos da linha de montagem de software. Contexto 
importa, e ser multitarefa nao funciona. Como resultado, temos um sistema de pro- 
du^ao ineficiente. Ja houve varias tentativas de resolver este problema de ineficiencia, 
sem sair do sistema de produ^ao de inspira^ao em fabricas, mas ainda nao descobri- 
mos como otimizar nossas fabricas de software a um nivel aceitavel. 

Se voce e “apenas” um programador, ou um testador, ou um designer, ou um 
arquiteto, voce vai se encontrar ocioso ou fazendo trabalho pesado e sem importan¬ 
ce durante varios momentos do seu projeto. Se voce e “apenas” um programador 
J2EE, ou um programador .NET, ou um programador de sistemas UNIX, voce nao 
vai ter muito a contribuir quando o foco de um projeto ou de uma empresa de mu- 
dar, mesmo que temporariamente, da sua area de foco. Nao e sobre onde voce esta 
na cadeia de valor de trabalho percebido do projeto (onde o arquiteto tern o posto 
mais alto da realeza). E sobre o quao util voce e. 

Se seu objetivo e ser a ultima pessoa de pe em meio a rodadas de demissoes ou 
terceiriza^ao de trabalho, e melhor se tornar “genericamente” util. Se voce tern medo 
de que o seu escritorio de desenvolvimento, que antes era lotado, vire a casa de um 
bando de gente estranha, ajudaria se voce percebesse que quando o time tern ape¬ 
nas algumas vagas, o “so testador” ou o “apenas codificador” nao serao requisitados. 
Melhor, se voce so quer se destacar e ser notavel, envolver-se no todo e o melhor que 
voce faz. 

Generalistas sao raros...epor isso, preciosos. 


O caminho para se tornar um generalista e nao se rotular com um papel especi- 
fico ou tecnologia. Podemos nos tornar flexiveis em nossas carreiras de muitas ma- 
neiras. Para entender o que significa ser um generalista, podemos dar uma olhada 
em como esta o cenario das carreiras de TI, em diferentes aspectos independentes. 
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Eu consigo pensar em cinco, mas e claro que ha uma infinidade (tudo depende de 
como voce separa os assuntos): 

• Degrau na escada da carreira; 

• Plataforma / OS; 

• Codigo x dados; 

• Sistemas x aplica^oes; 

• Negocio x TI. 

Essas sao diferentes formas pelas quais voce poderia abordar o problema de se 
tornar um generalista. Esta e apenas uma maneira de pensar sobre toda a sua car¬ 
reira, e voce provavelmente pode ter uma lista melhor para si proprio. Por agora, 
vamos discutir esses pontos. 

Primeiro, voce pode optar por ser um lider ou gerente, ou ser uma pessoa tec- 
nica. Ou, voce pode se autoclassificar um arquiteto em vez de ser um programador 
ou testador. A capacidade de ser flexivel nos papeis que voce pode e vai ter e um 
atributo cujo valor muitas pessoas nao compreendem. Por exemplo, enquanto um 
lider forte deve evitar ao maximo se intrometer, esse novo mundo de equipes de 
desenvolvedores terceirizados pode se beneficiar de uma pessoa que sabe como li- 
derar pessoas e projetos, mas tambem pode arrega^ar as mangas e corrigir alguns 
bugs criticos de ultima hora, enquanto a equipe offshore esta dormindo. O mesmo 
vale para um arquiteto de software que possa acelerar dramaticamente o progresso 
em um projeto se ele escrever um pouco de codigo. Quando se trata de atravessar 
hierarquias, nao e a relutancia que impede as pessoas de faze-lo. E a capacidade. 
Programadores nerds nao podem liderar, e os lideres e gerentes nao podem escrever 
codigo. E raro encontrar alguem seja bom nos dois. 

Suas habilidades transcendem tecnologias. 


Outra falha imperdoavel e encontrada quando falamos de plataformas e sistemas 
operacionais. Ser um cara UNIX que se recusa a trabalhar com Windows e cada vez 
mais inviavel. O mesmo vale para .NET vs J2EE ou quaisquer outras plataformas de 
infraestrutura. O tempo vai exigir que voce seja neutro com rela^ao a plataforma 
no seu ambiente de trabalho. Todos nos temos nossas preferences, mas voce vai 


30 



Casa do Codigo 


Capitulo 7. Seja generalista 


ter que deixar seus ideais em casa. Domine um e fique bom no outro. Suas habili- 
dades devem transcender a tecnologia e plataforma. Ela e apenas uma ferramenta. 
Se queremos alguem que so saiba Windows, podemos contrata-lo nas Filipinas. Se 
quisermos alguem que realmente entenda de Windows e UNIX e pode integra-los, 
provavelmente vamos procurar aqui por perto. Nao seja deixado de lado por causa 
de algo que e essencialmente espirito de equipe. 

A linha que divide o administrador de banco de dados (um papel solidificado 
em TI na ultima decada) e desenvolvedor de software tambem e tenue. Ser um ad¬ 
ministrador de banco de dados ou DBA, significa em muitos lugares saber como 
usar alguma ferramenta visual de administra^ao e como configurar um banco de 
dados. Voce nao precisa necessariamente saber muito sobre como usar o banco nas 
aplica^oes. Por outro lado, os desenvolvedores estao cada vez mais preguiijosos e 
ignorantes sobre como trabalhar com bancos de dados. Cada lado alimenta o outro. 

O que mais me surpreendeu quando eu entrei na area de TI era que muitos pro- 
gramadores (talvez a maioria) nao sabiam como configurar os ambientes que eles 
utilizavam para o desenvolvimento e para deploy. Eu trabalhei com desenvolvedores 
que nao conseguiam sequer instalar um sistema operacional em um computador se 
voce pedisse, muito menos configurar um servidor de aplica^oes para fazer o deploy 
das suas aplica^oes. E raro encontrar um desenvolvedor que realmente entende a 
plataforma em que esta trabalhando. As aplicanoes sao melhores por consequencia, 
o trabalho costuma ser feito mais rapido. 

Finalmente, como discutimos no capitulo 3, a barreira entre o negocio e TI deve 
ser derrubada ja! Comece a entender como sua empresa funciona. 

Fa£a algo 

1) Em um pedaijo de papel ou em uma lousa, liste as dimensoes em que voce pode 
ou nao estar generalizando seus conhecimentos e habilidades. Para cada dimen- 
sao, escreva sua especialidade. Por exemplo, se “sistema operacional” e uma de 
suas dimensoes, voce pode escrever Windows/.NET ao lado. Agora, a direita da 
sua especialidade, escreva um ou mais topicos que voce deveria aprender. Conti- 
nuando com o mesmo exemplo, voce pode escrever Linux/Java (ou mesmo Ruby 
ou Perl). 

Assim que possivel (mas ainda essa semana), pegue 30 minutos de seu tempo e 
comece a aprender alguma tecnologia que voce listou. Nao basta ler sobre ela. Se 
possivel, iaqa um hands-on. Se e uma tecnologia web, entao iaqa voce mesmo a 
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instala^ao e configura^ao do servidor. Se e um assunto relacionado a negocios, 
escolha um de seus clientes no trabalho e chame-os para almo^ar ou conversar. 
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“Como voce escreveria um programa, em Java puro, que trave a Java Virtual Ma¬ 
chine?” Silencio mortal. “Oi?” 

“Desculpa. Nao entendi. Voce pode repetir a pergunta, por favor?” A voz soava 
desesperada. Eu sabia que repetir a pergunta nao iria ajudar em nada. Entao, eu 
repeti a pergunta, devagar e em um tom de voz mais alto. “Como voce escreveria 
um programa, em Java puro, que faqa Java Virtual Machine parar de funcionar?” 

“Uh... desculpe. Eu nunca fiz isso.” 

“Eu sei que nao. Que tal essa pergunta: como e que voce escreveria um programa 
que NAO trave a JVM"? 

Eu estava procurando por programadores Java realmente bons. Para come^ar 
a entrevista, perguntei para esta pessoa (e todos os outros candidatos que eu havia 
entrevistado naquela semana) para avaliar a si mesmo em uma escala de um a dez. 
Ele disse nove. Estou esperando uma estrela aqui. Se esse cara se avalia de forma tao 
alta, por que ele nao consegue pensar em algum simples truque que trave a JVM? 

A falta de profundidade tecnica. 
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Muitos acreditam que ser especialista em algo significa que voce nao sabe outras 
coisas. 


Essa pessoa se dizia especialista em Java. Se voce o conhecesse em uma festa 
e perguntasse o que ele fazia para viver, ele diria: “Eu sou um desenvolvedor Java”. 
Ainda assim, ele nao conseguia responder a esta simples pergunta. Ele nao conseguia 
sequer chegar a uma resposta errada. Depois de intensas duas semanas e meia de 
entrevistas em uma viagem de recrutamento, esta foi a regra, nao a exce^ao. Milhares 
de especialistas Java tinham se candidatado para as vagas abertas, mas quase nenhum 
deles sabia explicar como Classloader Java trabalhava ou entao dar uma visao geral 
de como o gerenciamento de memoria funciona em uma JVM. 

Claro, voce nao tern que saber essas coisas para escrever codigo sob a supervisao 
de outros. Mas estas pessoas deveriam ser especialistas. 

Muitos acreditam que ser especialista em algo significa que voce nao sabe outras 
coisas. Eu poderia, por exemplo, chamar minha mae de especialista em Windows, 
porque ela nunca usou o Linux ou Mac OS X. Ou, eu poderia dizer que meus paren- 
tes na zona rural do Arkansas sao especialistas em musica country, porque nunca 
ouviram nada diferente. 

Imagine que voce visite o seu medico da familia, reclamando de um nodulo es- 
tranho no seu bra^o direito. O seu medico indica um especialista para fazer uma 
biopsia. E se esse especialista fosse uma pessoa cujas unicas credenciais como espe¬ 
cialista eram que ele nao compareceu as aulas na escola de medicina ou nunca teve 
experiencia em residences que nao eram diretamente ligadas ao procedimento es- 
pecifico que ele vai realizar hoje em voce? Eu nao quero dizer que eles foram mais 
fundo nos temas relacionados ao procedimento de hoje. E se ele tivesse apenas visto 
por cima essas assuntos e nao soubesse de mais nada? “E se essa maquina ali come^ar 
a apitar durante o procedimento?”, voce pode perguntar. “Ah, isso nunca aconteceu 
antes. Nao vai acontecer desta vez. Eu nao sei o que a maquina faz, mas ela nunca 
apita.” 

Felizmente, a maioria dos desenvolvedores de software nao e responsavel por si¬ 
tuates de vida ou morte. Se eles fracassarem, isso geralmente vai resultar em atrasos 
nos projetos ou bugs que simplesmente custarao dinheiro de seus empregadores, nao 
vidas. 

Infelizmente, a industria de software tern movimentado um monte desses espe- 
cialistas rasos, que usam o termo especialista como uma desculpa para saber so uma 


34 



Casa do Codigo 


Capitulo 8. Seja especialista 


coisa. Na industria medica, um especialista e alguem com profundo conhecimento 
de alguma area especifica. Doutores encaminham os pacientes para especialistas, 
porque, em certas circunstancias, o especialista pode cuidar melhor do paciente do 
que um clinico geral. 

Entao, o que um especialista de software deve ser? Eu posso lhe dizer o que eu 
estava procurando por toda a parte durante a viagem de recrutamento. Era por pes- 
soas que entendessem profundamente programa^ao Java e ambiente de implanta^ao. 
Eu queria pessoas que pudessem dizer “estive la, fiz isso” em 80% das situates e cuja 
profundidade de conhecimento passasse tranquilidade para as outras 20% das situa¬ 
tes. Eu queria alguem que, ao lidar com abstra^oes de alto nivel, entendesse os de- 
talhes da implementa^ao dessas abstraijoes. Eu queria alguem que pudesse resolver 
qualquer problema de implanta^ao que encontrassemos ou que ao menos soubesse 
a quern pedir ajuda se necessario. 

Este e o tipo de especialista que vai sobreviver na industria de TI. Se voce e um 
especialista em .NET, isso nao e uma desculpa para nao saber nada, alem de .NET. 
Isso significa que, se tern a ver com .NET, voce e o cara. Servidores IIS travados e 
precisando de reboot? “Nao tern problema.” Integra^ao de codigo fonte com o Visual 
Studio .NET? “Eu lhe mostro como.” Clientes a beira de um ataque de nervos por 
conta de problemas de performance que ninguem sabe o que e? “De 30 minutos.” 

Se isso nao e o que ser um especialista significa para voce, entao eu espero que 
nao saia falando que e um. 

Fa$a algo 

• Voce usa uma linguagem de programa^ao que compila e roda numa maquina 
virtual? Se assim for, levara algum tempo para aprender sobre os detalhes 
de como a VM trabalha. Considerando Java, .NET e Smalltalk, muitos livros 
e sites sao dedicados ao tema. E mais facil aprender sobre elas do que voce 
imagina. 

Independente de a sua linguagem se basear em uma VM, leva algum tempo 
para estudar o que acontece quando voce compila um arquivo fonte. Como e 
que o codigo que voce digitou passa de texto legivel para as instrucjoes que um 
computador pode executar? O que significaria escrever o seu proprio compi- 
lador? 

Quando voce importa ou usa bibliotecas externas, de onde elas vem? O que 
realmente significa importar uma biblioteca externa? Como e que o seu com- 
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pilador, sistema operacional, ou maquina virtual liga varios peda^os de codigo 
para formar um sistema coerente? Aprender esses pontos fara com que voce 
fique muitos passos mais proximos de ser um especialista na sua tecnologia 
preferida. 

• Encontre uma oportunidade — no trabalho ou fora dele — de dar uma aula 
sobre algum aspecto de uma tecnologia em que voce gostaria de se aprofun- 
dar. Como voce vera em “Seja um mentor”, capitulo 14, o ensino e uma das 
melhores maneiras de aprender. 


36 



Capitulo 9 

Nao coloque todos os seus ovos 
num so cesto 


Uma vez, enquanto gerenciava um time de desenvolvedores, eu perguntei a um dos 
meus funcionarios: “O que voce quer fazer com sua carreira? O que voce quer ser?” 
Fiquei muito decepcionado com sua resposta: “Quero ser um arquiteto J2EE” Eu 
perguntei: “Por que nao um designer Microsoft Word ou um instalador RealPlayer?” 

Ele queria fazer sua carreira em torno de uma tecnologia especifica, criada por 
uma empresa especifica, da qual ele nao era um empregado. E se a empresa acabar? 
E se sua tecnologia se tornar obsoleta? Por que voce quer confiar sua carreira a uma 
empresa de tecnologia? 

De alguma maneira, como uma industria, nos mesmos nos enganamos ao pen- 
sar que lider de mercado e a mesma coisa que padrao. Assim, para algumas pessoas, 
parece inteligente fazer com que o produto de uma empresa fa 9 a parte da sua iden- 
tidade. Pior ainda, alguns baseiam suas carreiras em torno de produtos que nem 
lideres de mercado sao — pelo menos ate suas carreiras falharem miseravelmente e 
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sua unica escolha for repensar sua estrategia perdedora. 

Vamos parar para lembrar que devemos pensar na nossa carreira como um ne¬ 
gocio. Embora seja possivel construir um negocio que seja um parasita de outro 
negocio (como empresas que constroem softwares de remo^ao de spyware para su- 
prir falhas de seguran^a do navegador da Microsoft), como uma pessoa, isso e uma 
coisa extremamente arriscada de se fazer. Uma empresa, como a do exemplo do 
spyware, geralmente pode reagir as mudan^as no mercado, como uma melhoria na 
seguran^a do navegador da Microsoft (ou a Microsoft decidir entrar no mercado de 
remo^ao de spyware), enquanto que uma pessoa nao tern a mao de obra ou dinheiro 
sobrando, para de repente, mudar de dire<;ao na carreira. 

Uma visao centrada apenas nofornecedor e uma visao miope. 


O lado triste da visao centrada no fornecedor e que, normalmente, os detalhes de 
implementa^ao do software de um fornecedor sao um segredo. Voce pode aprender 
bastante sobre o software de alguem, ate chegar na barreira do servico profissional. 
Essa e uma barreira artificial que a empresa impoe entre voce e a solu^ao para um 
problema possivel, dessa forma, ela pode lucrar vendendo o suporte. Algumas vezes, 
essa barreira e proposital, e as vezes e um efeito colateral da tentativa da empresa de 
proteger sua propriedade intelectual (nao compartilhando o codigo-fonte). 

Assim, apesar de que o investimento em uma unica determinada tecnologia seja 
quase sempre uma ma ideia, se voce precisar fazer isso, considere focar em uma 
op^ao open source, ao inves de uma comercial. Mesmo que voce nao possa ou nao 
queira usar uma solu^ao open source no seu trabalho, use-a para conseguir ir mais 
a fundo na tecnologia. Por exemplo, voce pode querer se tornar um especialista em 
como funcionam os servidores de aplica^ao J2EE. Em vez de concentrar seus esforijos 
sobre os detalhes de como configurar e implantar um servidor de aplica^ao comercial 
(afinal, qualquer um pode descobrir como ajustar as configurates em um arquivo 
de configurate, certo?), baixe o codigo fonte do JBoss ou Geronimo e reserve um 
tempo para si mesmo, nao so para aprender a operar os servidores, mas para estudar 
suas partes internas. 

Em pouco tempo, voce vai perceber que naturalmente o seu ponto de vista vai 
mudar. Esse negocio de J2EE (ou seja la o que voce escolheu estudar) realmente nao 
e nada de tao especial. Agora que voce ve os detalhes da implementa^ao, pode per¬ 
ceber que ha padroes conceituais ali no meio. E come^ar a perceber que, seja com 
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Java ou outra linguagem ou plataforma, arquitetura distribuida e arquitetura distri- 
buida. Sua visao aumenta e sua mente come^a a abrir. Voce come^a a perceber que 
os conceitos e padroes que o seu cerebro esta organizando e assimilando sao muito 
mais escalaveis e universais do que qualquer tecnologia de uma empresa especifica. 
“Nao importa o fornecedor, eu sei como criar um sistema!” 

Fa$a algo 

1) Tente um projeto pequeno, duas vezes. Tente uma vez em sua tecnologia padrao e, 
depois, da forma mais idiomatica possivel, facja em uma tecnologia concorrente. 
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Ame-o ou deixe-o 


Pode soar como uma especie de historinha cliche feita pra despertar aquela exalta^ao 
idealista em voce, mas e muito importante para deixar de falar. Se voce quer ser 
realmente bom no seu trabalho, voce tern que ser apaixonado por ele. Se voce nao 
da a minima pra ele, isso vai transparecer. 

Quando minha esposa e eu nos mudamos para Bangalore, eu estava bem ani- 
mado. Pela primeira vez na minha carreira, estava ansioso para encontrar tecno- 
logos com paixao por aprender. Estava esperando uma vida pos-trabalho cheia de 
reunioes de grupo de usuarios e profundas discussoes filosoficas sobre tecnicas e me- 
todologias de desenvolvimento de software. Eu estava esperando encontrar o Silicon 
Valley da India cheio de artesaos, entusiastas da grande arte de desenvolver software. 

O que eu encontrei foi um monte de gente que estava la so pra receber seu salario 
e poucos artistas apaixonados. 

Era igual ao lugar de onde vim. 

Claro, na hora eu nao percebi que era igual ao lugar de onde vim. Eu tinha algu- 
mas referencias dos Estados Unidos, mas sempre achei que era porque eu trabalhava 
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em cidades ruins ou em empresas com ambiente ruim. Sempre achei que minhas 
primeiras experiences na area de TI tinham sido exce^oes. “Deve ser assim com 
a maioria dos desenvolvedores”, pensava. “Eu so nao encontrei o ambiente certo 
ainda.” 

Comecei a trabalhar no departamento de TI da minha universidade atraves de 
uma recomenda^ao do meu amigo Walter, que tinha me visto trabalhar com com- 
putadores, o suficiente para saber que eu provavelmente poderia faze-los trabalhar 
melhor do que a maioria das pessoas que precisavam de ajuda na universidade. Eu 
nao acreditava que eu podia, sem ter nenhum tipo de treinamento. Eu era apenas um 
tocador de saxofone que gostava de jogar videogame. Mas Walter me candidatou em 
uma vaga e marcou uma entrevista para mim. Fui contratado sem nem uma unica 
questao tecnica ter sido perguntada, e era para come^ar imediatamente. 

Quando eu apareci no trabalho, estava morrendo de medo de ser descoberto 
como um charlatao, o que eu realmente era. “O que e que este saxofonista esta fa- 
zendo aqui com a gente, profissionais treinados?” Afinal, eu estava trabalhando com 
gente que tinha niveis avan^ados em ciencia da computa^ao. E aqui estava, tendo 
cursado so uma parte da faculdade de Musica, tentando me encaixar como se eu 
soubesse alguma coisa. 

Depois de alguns dias de trabalho, a verdade come^ou a afundar. “Essas pes¬ 
soas nao fazem ideia do que estao fazendo!” Na verdade, algumas pessoas estavam 
me observando trabalhar e tomando notas! Pessoas com mestrado em ciencia da 
computacao! 

Minha primeira reacjao foi assumir que eu estava cercado por idiotas. Afinal, eu 
nao tinha nenhum treinamento formal. Passei minhas noites tocando em bandas 
de bar e meus dias jogando videogame. Eu tinha aprendido a trabalhar com com- 
putadores so porque eu estava interessado neles. Na verdade, eu aprendi a escrever 
programas porque eu queria fazer meus proprios jogos de computador. Eu chegava 
em casa tarde depois de uma noite ensurdecedora em algum bar e ficava ate o sol nas- 
cer em sites Gopher com tutoriais sobre programa^ao. Ai eu ia dormir, acordava e 
continuava estudando ate que a hora em que eu tinha que sair e tocar novamente. Eu 
parava meus estudos com meus amados jogos, comia e depois voltava para brincar 
com Gopher e qualquer compilador que eu conseguisse fazer funcionar. 

Trabalhe porque voce nao poderia nao trabalhar. 


Pensando bem, eu era viciado, mas de um jeito bom. Meu desejo por criar tinha 
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sido despertado em grande parte da mesma forma que quando comecei a escrever 
musica classica ou tocar jazz. Eu era obcecado por aprender tudo o que eu pudesse. 
Eu nao estava ali para uma nova carreira. Na verdade, muitos dos meus amigos 
musicos achavam isso uma irresponsavel distra^ao da minha carreira atual. Eu estava 
la porque eu nao poderia nao estar. 

Esta foi a diferen<pa entre eu e os meus superestudados, mas de baixo rendimento, 
colegas de trabalho. Paixao. 

Essas pessoas nao tinham ideia de por que eles estavam na area de TI. Eles se 
encontraram por acaso em suas carreiras, porque acharam que programar podia pa- 
gar bem, porque os seus pais os incentivaram ou porque nao conseguiam pensar em 
um curso melhor na faculdade. Infelizmente o seu desempenho no trabalho refletia 
isso. 

Se voce pensar nas biografias que voce leu ou nos documentarios a que assistiu 
sobre os grandes nomes em varios campos, esse mesmo padrao de vicio e comporta- 
mento apaixonado aparece. Diz-se que o grande saxofonista de jazz, John Coltrane, 
praticava tanto que seus labios chegavam a sangrar. 

E claro, o talento natural tern um grande papel na habilidade. Nem todos podem 
ser Mozart ou Coltrane. Mas todos nos podemos dar um grande passo longe da 
mediocridade encontrando um trabalho pelo qual somos apaixonados. 

Pode ser um dominio ou negocio que lhe interesse. Ou, por outro lado, pode 
ser uma tecnologia especifica ou dominio de negocio que o afunde. Ou um tipo de 
empresa. Talvez voce esteja destinado a pequenas equipes ou a times grandes. Ou a 
processos rigidos. Ou a processos ageis. Qualquer que seja a combina^ao, leva algum 
tempo para encontrar a sua. 

Voce pode fingir por um tempo, mas a falta de paixao vai pegar voce e seu tra¬ 
balho. 

Sendo um oportunista em serie 

por James Duncan Davidson 

Desde o initio, eu nao tive o que muitos consideram uma carreira tradicional. 
Pelo contrario, tern sido muito mais um caminho de seguir as oportunidades con- 
forme elas aparecem. A primeira apareceu enquanto eu estava na escola trabalhando 
em uma licenciatura em arquitetura. Eu tinha decidido na idade de 15 ou 16 anos que 
eu queria ser um arquiteto, e passei muito tempo investindo no futuro. Mas as se- 
mentes do que realmente seria a minha carreira depois da escola foram plantadas 
em meu fascinio precoce com sistemas online BBS. Eu era um daqueles garotos que 
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amavam o modem de 300 no PC da familia. Isso me levou, eventualmente, para a 
internet, que por sua vez me levou a Gopher e, entao, World Wide Web. 

A web imediatamente me fisgou. Eu construi varios sites pessoais em rapida 
sequencia e aproveitei toda a tecnologia a minha disposftao, ensinando a mim 
mesmo conforme necessario. Na epoca, eu pensei neste trabalho como experimen- 
tos em cyber-architetura. Parece muito grandioso e ate mesmo bastante idiota agora, 
mas era o mundo em que nos dos primeiros tempos da web viviamos. Estavamos 
tentando imaginar o que o futuro poderia trazer. 

Naturalmente, o verdadeiro trabalho de construir o futuro da internet nao estava 
acontecendo nos laboratories de arquitetura. Ele estava acontecendo no mundo dos 
negocios. Em pouco tempo, e com base no que eu tinha feito com o meu site pu¬ 
blico, fui contatado por uma startup que estava construindo websites para os Hil¬ 
ton, Better Business Bureau e semelhantes. Eles tinham visto os sites eu havia cons- 
truido, e, aparentemente, eu tinha o conjunto de habilidades de que eles precisavam. 
Ofereceram-me um trabalho com o que parecia, na epoca, um salario ridiculamente 
grande. Aceitei-o, imaginando que eu poderia aproveitar a onda por um tempo, ga- 
nhar algum dinheiro, e voltar para a escola em poucos anos. 

Foi em 1995. Mai sabia eu quao longe as coisas iriam e aonde um pouco de von- 
tade de mergulhar em algo novo iria me levar. 

Enquanto eu ajudava a construir a primeira versao do website Hilton, que tinha 
posicionamento de reservas em tempo real, aprendi como construir sites usando 
uma variedades de tecnologias do lado do servidor. Em poucos meses, eu passei de 
aprendiz a criador de meus proprios frameworks. Olhando para tras, parece ridiculo, 
mas naquele momento, isso era o que era necessario. Eu vi uma abertura, aceitei-a, 
e apostei nela por tudo que valia, reinventando a mim mesmo conforme necessario. 

Uma coisa levou a outra. Em 1997, fui para a JavaSoft trabalhar aplica^oes servi- 
doras, e em poucos anos, acabei encarregado da especifica^ao Servlet. Infelizmente, 
era um esfor^o subfinanciado, e eu nao tinha uma equipe para me ajudar a fazer tudo 
que precisava ser feito, incluindo construir uma nova implementa^ao de referenda. 
Mas eu nao deixei isso me parar, e dei inicio ao desenvolvimento de uma implemen- 
ta^ao completamente nova, que eventualmente foi lambada como o Kit JavaServer 
Web Development. Poucos se lembram desse software. Mas a maioria dos que tra- 
balham com Java sabe sobre a versao seguinte daquele codigo. E o chamado Tomcat. 
E ele foi lan^ado mundialmente via Funda^ao Apache com um socio chamado Ant. 
A historia por tras desse lan^amento daria um livro. O suficiente e dizer que tudo 
aconteceu gramas a um perfeito conjunto de oportunidades nas quais estive disposto 
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a apostar. 

Depois de trabalhar na Sun por quatro anos e encarar uma questao do tipo “O 
que eu devo fazer agora?” decidi me tornar independente. Escrevi livros para a 
O’Reilly, desenvolvi software para Mac, desenvolvi alguns softwares proprios que 
acabei nao laruymdo. E terminei fazendo um pouco de desenvolvimento Ruby on 
Rails. Ser um desenvolvedor de software independente foi bom para mim e sou bas- 
tante bom nisso. Mas ao longo do caminho, um hobby que eu estava perseguindo 
come^ou a se transformar em uma propria carreira. 

Alem de ser um estudante de arquitetura que se tornou tecnologo, eu era tam- 
bem um fotografo havia um bom tempo. Minha avo tinha me ensinado o basico. 
Meus pais me encorajaram. Como resultado, ate onde posso me lembrar, eu tinha 
uma camera por perto. Isso tern sido uma grande parte da minha vida. Alias, o soft¬ 
ware nao lan^ado que eu escrevi para mim mesmo depois de deixar a Sun era para 
o trabalho com fotografia. 

Em 2005, dez anos depois que eu fiz uma pausa e mudei de estudante de arqui¬ 
tetura para desenvolvedor de software, fui chamado por meus amigos do grupo de 
conferences O’Reilly. Eles precisavam de alguem para documentar seus eventos e 
perguntaram se eu nao estaria interessado em ir tirar algumas fotos. Eu aceitei, mas 
em vez de somente tirar algumas fotos, fui alem da minha causa. Fiquei maluco e 
trabalhei em todas as sessoes importantes, e postei imagens no Flickr para forne- 
cer um retorno extremamente rapido. Fui convidado de novo e, nos ultimos quatro 
anos, construi um negocio em torno disso com uma boa gama de clientes. 

Enquanto escrevo isso, eu ainda fa 90 codigo de tempos em tempos, e ate de- 
senvolvo um pouco para alguns clientes. Mas, na maior parte, eu sou um fotografo 
full-time nos dias de hoje. Contudo, isso pode mudar. Nunca se sabe. E dificil dizer 
o que o futuro trara. 

O que eu sei e que sou um oportunista. Quando vejo algo interessante e excitante 
para mim, eu mergulho dentro disso e fa<;o o que for preciso para obter sucesso. Ge- 
ralmente, isso significa aprender habilidades e desenvolver novas capacidades. Al¬ 
guns podem achar que construir novas habilidades e um entrave, mas por alguma 
razao, eu adoro aprender como fazer coisas novas. Afinal, novas habilidades per- 
mitem que voce fa<pa coisas novas. E eu nunca me defini por minhas habilidades. 
Ao contrario, sempre me defini pelo que fiz e pelo que eu quero fazer em seguida. 
Habilidades sao apenas um caminho para chegar la. 

James Duncan Davidson e um programador e fotografo. 
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Fa$a algo 

1) Va encontrar um emprego pelo qual voce seja apaixonado. 

2) Come^ando na proxima segunda-feira, mantenha um registro simples nas pro- 
ximas duas semanas. A cada dia de trabalho, avalie seu nivel de empolga^ao de 1 
a 10. 1 significa que voce preferia estar doente do que ir ao trabalho e 10 significa 
que voce nao consegue hear na cama, pois esta consumido pela ideia de finalizar 
a sua proxima tarefa. 

Depois de duas semanas de registro, analise os resultados. Houve picos? Houve 
tendencias? Foi tudo baixo ou tudo alto? Qual seria a sua nota media se isso fosse 
um teste de escola? 

Para as proximas duas semanas, toda manha planeje como voce fara amanha ser 
um 10. Planeje o que voce vai fazer hoje para fazer com que amanha seja um des¬ 
ses dias de trabalho que voce mal pode esperar para come^ar. Cada dia, registre 
o nivel de empolga^ao do dia anterior. Se depois de duas semanas as coisas nao 
estiverem boas, talvez seja hora de pensar em uma mudan^a. 
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Aprenda a pescar 


Lao Tzu disse: “De a um homem um peixe, e alimente-o por um dia. Ensine um 
homem a pescar, e alimente-o por toda a vida”. Isso e tudo muito certo. Mas Lao Tzu 
nao menciona a situa^ao em que o homem nao quer aprender a pescar e lhe pede 
outro peixe no dia seguinte. Educa^ao exige tanto um professor como um estudante. 
Muitos de nos somos muitas vezes relutantes em ser um estudante. 

Nao espere que lhe digam. Pergunte! 


Mas o que e um peixe na industria de software? E o processo de utiliza^ao de 
uma ferramenta ou alguma parte de uma tecnologia ou uma inform a<pao especifica 
do dominio de negocio no qual voce esta trabalhando. E como baixar uma branch es¬ 
pecifica do sistema no controle de versao, ou colocar no ar um servidor de aplicaijoes 
para o desenvolvimento. Muitos de nos interpretam isso como definitivo. “Alguem 
pode cuidar disso para mim”, voce pode pensar. O cara do build conhece o sistema 
de controle de versao. Voce so precisa pedir a ele para definir as coisas quando voce 
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precisar. A equipe de infraestrutura sabe como os firewalls entre voce e seus clientes 
sao configurados, por isso, se voce tem uma necessidade, basta enviar um e-mail e a 
equipe vai cuidar disso. 

Quem quer bear a merce de outra pessoa? Ou pior: se voce estivesse contratando 
alguem para fazer um trabalho para voce, voce ia gostar que ele estivesse a merce dos 
especialistas? Eu nao. Eu ia querer contratar alguem autossuficiente. 

O jeito mais obvio para come^ar e aprender as ferramentas do seu mercado. Con- 
trole de versao, por exemplo, e uma ferramenta poderosa. Uma parte importante da 
sua furujao e focada em tornar os desenvolvedores mais produtivos. Nao e apenas 
o lugar onde voce coloca o seu codigo quando voce o julga pronto, e voce nao deve 
trata-lo como tal. E uma parte integrante do seu processo de desenvolvimento. Nao 
deixe que uma coisa tao importante seja como um voodoo para voce. Um desenvol- 
vedor autossuficiente pode facilmente ver as diferen^as entre a versao de um projeto 
que ele pegou e a ultima versao estavel no repositorio. Ou talvez voce precise baixar 
a versao do ultimo release e fazer uma corre^ao de um bug. Se aparece um bug erf- 
tico no meio da noite, voce nao vai querer chamar alguem para pedir que lhe deem a 
versao correta do codigo para voce resolver os problemas. Isso vale para IDEs, siste- 
mas operacionais e praticamente todas as partes de infraestrutura do seu codigo ou 
processo. 

Igualmente importante e a plataforma tecnologica que voce esta usando. Por 
exemplo, voce pode estar desenvolvendo aplica^oes usando J2EE. Voce sabe que deve 
criar varias classes, interfaces e scripts de deploy. Mas voce sabe por que? Voce 
sabe como essas coisas sao usadas? Quando voce inicia um container J2EE, o que 
realmente acontece? Voce pode nao ser um desenvolvedor de servidor de aplica^ao, 
mas saber como eles funcionam possibilita que voce desenvolva codigo confiavel 
naquela plataforma e resolva os problemas quando algo der errado. 

Uma maneira particular e facil de ser folgado e usar varios wizards que geram 
codigo para voce. Isso e particularmente predominante no mundo de desenvolvi¬ 
mento Windows, em que, as ferramentas de desenvolvimento tornam varias tarefas 
realmente faceis. O lado negativo e que muitos desenvolvedores Windows nao tem 
ideia de como seus codigos realmente funcionam. O trabalho dos wizards continua 
sendo um misterio magico. Nao me leve a mal - geradores de codigo, quando usa- 
dos corretamente, podem ser uma ferramenta muito util. Por exemplo, sao eles que 
traduzem C# de alto nfvel para bytecodes que podem rodar em .NET. Voce obvi- 
amente nao gostaria de ter que escrever todos esses bytecodes voce mesmo. Mas, 
especialmente em nfveis mais altos, deixar os wizards fazerem seu trabalho torna o 
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seu conhecimento raso e o deixa limitado ao que as ferramentas podem fazer por 
voce. 

Nos podemos facilmente ignorar o “peixe” em nosso dominio de negocio. Se 
esta trabalhando para uma empresa de hipotecas, voce pode pedir para um especi- 
alista o calculo da taxa de juros para cada cenario que voce precisar nos testes, ou 
poderia voce mesmo aprender como calcular. Embora interaijoes com seus clientes 
sejam boas, e e bom clarear os requerimentos do negocio com eles (o contrario de 
entender pela metade e preencher os detalhes voce mesmo), imagine quao rapido 
voce poderia avan^ar se realmente soubesse os detalhes do dommio em que esta tra¬ 
balhando. Voce provavelmente nao vai saber cada regra de negocio - e nem e sua 
fun^ao. Mas voce pode, pelo menos, aprender o basico. Muitas das melhores pessoas 
que trabalham com software, com quern trabalhei durante anos, tornaram-se mais 
especialistas em seus dominios do que ate alguns de seus clientes. Isso resulta em 
produtos melhores. Alguem que e ignorante em dominio vai deixar passarem erros 
bobos - erros que um conhecimento basico poderia evitar. Alem disso, ele trabalha- 
ria mais lentamente (e custaria mais a empresa) do que o desenvolvedor que entende 
do negocio. 

Para nos, desenvolvedores de software, a inten^ao de Lao Tzu pode ser igual- 
mente interpretada como “Pe^a um peixe; coma por um dia. Pe^a a alguem para 
ensinar-lhe a pescar; coma para a vida toda”. Melhor ainda, nao pe^a para ser ensi- 
nado - va aprender voce mesmo. 

Fa9a algo 

1) Como e por que? - tanto enquanto voce esta sentado lendo este livro, ou na 
proxima vez em que estiver no trabalho, pense sobre as partes do seu trabalho 
que voce entende por completo. Voce pode se fazer duas perguntas extremamente 
uteis sobre qualquer assunto para mergulhar fundo nele: como isso funciona? E 
por que isso tem que acontecer? 

Voce pode nao conseguir responder as perguntas, mas o simples ato de faze-las 
vai levar sua mente a um novo quadro e pode gerar um nivel mais alto de cons¬ 
cience sobre seu ambiente de trabalho. Como o servidor IIS acaba passando 
requests para minhas paginas ASP.NET? Como eu devo gerar essas interfaces e 
scripts de deploy para minhas aplicaijoes EJB? Como meu compilador lida com 
linkagem dinamica ou estatica? Como calculamos a taxa de modo diferente se 
um comprador mora em outro estado? 
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Claro, a resposta para qualquer dessas perguntas levara a uma outra potencial 
oportunidade de se fazer a pergunta mais uma vez. Quando voce nao puder mais 
avan^ar na arvore do como e do porque, voce provavelmente tera ido longe o 
suficiente. 

2) Dica - escolha uma das mais criticas, porem negligenciadas, ferramentas da sua 
caixa de ferramentas e foque nela. Talvez seja seu sistema de controle de ver- 
sao, talvez uma biblioteca que voce use bastante mas procurou apenas superfici- 
almente, ou talvez o editor que voce usa pra programar. 

Quando voce escolher a ferramenta, reserve um pequeno periodo de tempo todos 
os dias para aprender uma coisa nova sobre ela que vai lhe tornar mais produtivo 
ou lhe dar mais controle sobre seu ambiente de desenvolvimento. Voce pode, por 
exemplo, escolher dominar o GNU Bourne Again Shell, tambem conhecido como 
bash. Durante um desses momentos em que sua mente come^a a fugir do que 
deve ser feito, em vez de ir para o Slashdot ou Facebook, voce poderia procurar na 
internet por dicas de bash. Em um minuto ou dois, voce deve encontrar algo util 
que voce nao sabia sobre como usar o shell. Claro, agora que tern um novo truque, 
voce pode mergulhar em suas entranhas com uma serie de como e porques. 
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No capitulo anterior, nos discutimos a importancia de fazer uma escolha intentio¬ 
nal sobre o dominio de negocio no qual voce trabalha. Conhecimento de dominio, 
sendo na melhor das hipoteses um diferencial para empregos e na pior das hipote- 
ses um estraga-prazeres, nao e algo que voce deva subestimar. Antes de fazer um 
investimento para aprender os pros e contras de um dominio de negocios, voce de- 
veria se certificar de que esta investindo na coisa certa para voce e para a situa^ao do 
mercado. 

Mas ha uma parte do conhecimento que nao e nem tecnica nem de dominio es- 
pecifico e nao sera ultrapassada em breve: o basico de finan^as. Independentemente 
da sua linha de negocio, se e de manufaturas, assistencia medica, sem fins lucrativos, 
ou uma institui^ao educational, ainda se trata de negocios. E isso e por si so uma 
area de conhecimento que alguem pode - e ate deve - aprender. 

Eu me lembro de quando eu era um jovem programador indo para reunioes 
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da equipe, meus olhos vidrados enquanto algum lider, com quem eu nunca tinha 
trabalhado diretamente, mostrava um monte de numeros que eu acreditava serem 
completamente irrelevantes para mim. Eu so quero voltar e terminar afuncionalidade 
que estou trabalhando, eu choramingava para mim mesmo. Meus colegas sentavam- 
se juntos, parecendo uma fila de criamjas contorcidas numa longa viagem de carro. 
Nenhum de nos entendia o que estava sendo apresentado, e nenhum de nos se impor- 
tava. Nos culpavamos os gerentes incompetentes que haviam convocado a reuniao, 
pelo que sentiamos que era uma completa perda de tempo. 

Voce nao pode criativamente ajudar em um negocio antes de saber como ele funciona. 


Olhando para tras, eu percebo como nos eramos bobos. Trabalhavamos para 
uma empresa, e nossa fun^ao era contribuir para ou fazer, ou economizar dinheiro 
para aquela empresa. Ainda assim nao entendiamos o basico de como um nego¬ 
cio se torna lucrativo. Pior ainda, nos nao pensavamos que era nosso dever saber. 
Nos eramos programadores e administradores de sistema. Pensavamos que nossos 
trabalhos eram estritamente sobre aqueles topicos aos quais nos devotavamos. Con- 
tudo, como nos supostamente poderiamos contribuir criativamente para que aquele 
negocio fosse rentavel, se nem mesmo entendiamos como isso funcionava? 

O uso da palavra criativamente no paragrafo anterior e a chave. E plausivel ter 
a visao de que somos, de fato, especialistas em TI e que e para isso que somos pa- 
gos. Dados os projetos e lideran^a corretos, nos deveriamos nos esforijar em tarefas 
que contribuissem para a empresa. Nao precisamos entender totalmente como uma 
empresa opera para dar-lhe valor. 

Mas para criativamente adicionar valor, e preciso uma compreensao mais com¬ 
pleta do ambiente de negocios em que voce trabalha. No mundo dos negocios, ou- 
vimos a frase ponto de partida o tempo todo. Quantos de nos realmente entendem 
o que e o ponto de partida e o que contribui para ele? Mais importante, quantos de 
nos realmente entendem como nos contribuimos para o ponto de partida? A or- 
ganiza^ao e um centra de custo ou de lucres (voce adiciona ou retira do ponto de 
partida)? 

Conhecer a conduta financeira - e linguagem - da sua empresa vai lhe propor- 
cionar a habilidade de fazer mudan^as significativas, em vez de tentar acertar no 
escuro em coisas que lhe parecem intuitivamente certas. 
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Fa^a algo 

1) Procure um livro basico sobre negocios, e trabalhe com ele. Uma dica para en- 
contrar um bom livro com uma visao geral e procurar por livros sobre MBA. Um 
desses livros que eu acho particularmente util (e agradavelmente curto) e o The 
Ten-Day MBA [9]. Voce realmente pode conclui-lo em dez dias. Ele nao custa 
caro. 

2) Pecpa a alguem para orienta-lo na area de fmamjas da sua empresa e expicar como 
funcionam as coisas (se isso for uma informa^ao que sua empresa nao se importe 
em compartilhar com seus funcionarios). 

3) Explique para eles de volta. 
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Encontre um mentor 


Uma coisa que a cultura musical do jazz realmente acertou foi a pratica de mentoria. 
No mundo do jazz, e comum os jovens musicos procurarem os mais experientes, que 
os carregarao sob sua asas e passarao seus conhecimentos de jazz. Mas isso nao para 
por ai. Esses musicos mais velhos geralmente servem como um conselheiro de car- 
reira, e da vida toda. Em troca, os musicos jovens sao devotamente fieis, construindo 
uma rede de apoio de apreciadores fanaticos em torno de seus mentores. 

Contatos sao feitos e musicos sao contratados todos os dias por meio desses rela- 
cionamentos. A sociedade do jazz criou uma cultura auto-organizada e um conjunto 
de costumes em torno do relacionamento com o mentor. E um sistema que funciona 
tao bem que voce suspeitaria que ele e guiado por algum tipo de entidade organiza- 
dora. 

E OK depender de alguem. So tenha certeza de que e apessoa certa. 


No mundo profissional tradicional (e especificamente na area de TI), nos esta- 
mos menos propensos a pedir ajuda uns aos outros. Depender dos outros e fre- 
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quentemente visto como um sinal de fraqueza. Temos medo de admitir que nao 
somos perfeitos. Tudo e competi^ao. Apenas os fortes sobrevivem, e isso e tudo. In- 
felizmente, isso leva a um sistema de mentoria extremamente subdesenvolvido. Se 
tivessemos que perguntar a um grupo de musicos de jazz: “Quern e seu mentor?”, a 
maioria deles teria uma resposta. Agora fa<;a a mesma questao para programadores. 
Nos Estados Unidos, eles provavelmente responderiam “O que?” 

Nem sempre foi assim por aqui. A historia do oeste inclui um prospero sistema 
de mentoria profissional, que vem desde a Idade Media. A abordagem do artesatado 
ao treinamento profissional era ainda mais forte e mais formalizado que o sistema 
que evoluiu na cena musical. Pessoas jovens come^avam suas carreiras profissionais 
como aprendizes de respeitaveis mestres artesaos. Elas trabalhavam em troca de um 
salario nominal e pelo privilegio de aprender com o mestre, cuja obriga^ao era trei- 
nar os discipulos para criarem coisas seguindo a mesma tradi^ao (e qualidade) que 
a sua propria. 

O primeiro e mais importante proposito de um mentor e ser um modelo a seguir. 
E dificil saber o que e possivel ser feito ate que voce veja alguem que possa ir alem dos 
limites que voce conhece. Um modelo estabelece o padrao do que “bom” significa. 
Se voce se imaginasse como um jogador de xadrez, por exemplo, so o fato de poder 
veneer as pessoas de sua familia imediata pode ser muito bom. Contudo, se voce 
jogasse contra um competidor de campeonatos, voce descobriria que o xadrez e um 
jogo muito mais denso do que voce jamais pensava. Se voce fosse jogar contra um 
grande mestre, voce teria outra revela^ao. Se voce continuasse jogando e derrotando 
apenas os membros de sua familia, voce poderia ficar com a ideia de que voce e 
realmente bom no xadrez. Sem um modelo a seguir, nao ha incentivo para melhorar. 

Um mentor tambem pode dar estrutura para seu processo de aprendizagem. 
Como voce viu no capitulo anterior, voce tern uma enorme quantidade de escolhas 
para fazer sobre as tecnologias e dominios em que vai investir. As vezes, muitas pos- 
sibilidades podem o travar. Com certeza, e melhor estar se movendo em uma dire^ao 
do que ficar sentado parado. Um mentor pode ajudar a escolher no que focar suas 
energias. 

Quando eu comecei minha carreira, trabalhando com suporte, eu conheci um 
santo chamado Ken, que era um dos administradores da rede da nossa universidade. 
Ele veio me salvar de um grande problema com a rede NetWare do nosso campus, 
que estava atrapalhando os alunos que tentavam usar o laboratorio de informatica. 
Quando o incitei a me dar direijoes sobre como me tornar mais bem informado e 
autossuficiente, ele me deu uma simples dica: mergulhe nos services de diretorio, 
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aprenda uma distribui^ao UNIX, e domine uma linguagem de script. 

Ele escolheu tres habilidades para eu aprender, dentre as infinitas disponiveis. E, 
com a confian^a que essa pessoa, quem eu considerava ser um mestre, as prescreveu, 
eu me dispus a aprender essas tres habilidades. Minha carreira desde entao tern sido 
construida sobre o alicerce desses conhecimentos, todos os tres, os quais ainda sao 
completamente relevantes para tudo. Eu fa^o isso. Nao e que o caminho que Ken 
me deu foi a resposta absolutamente certa - nao ha respostas absolutamente certas. 
O importante e que ele estreitou a longa lista de habilidades que eu poderia estar 
aprendendo, transformando-a em uma curta lista de habilidades que eu, de fato, 
aprendi. 

O mentor tambem serve como alguem de confian^a que pode observar e julgar 
suas decisoes e seu progresso. Se voce e um programador, voce pode mostrar seus 
codigos e obter indicadores. Se voce esta planejando fazer uma apresenta^ao no 
escritorio ou em alguma reuniao de um grupo de usuarios locais, voce pode mostra- 
la de antemao para seu mentor para receber feedback. Um mentor e alguem em que 
voce pode confiar o suficiente para perguntar “O que deveria ser diferente em mim 
enquanto profissional?”, porque voce sabe que ele nao vai apenas critica-lo, mas sim 
ajuda-lo a melhorar. 

Finalmente, assim como no jazz, voce nao apenas cria uma liga^ao pessoal e de 
responsabilidades para com seu mentor, mas o inverso tambem acontece. Se meu 
papel, em um relacionamento, e ajudar alguem, eu invisto no sucesso dessa pessoa. 
Estou ajudando alguem ao longo de sua carreira, por um caminho que eu acredito 
ser o correto. Portanto, se o caminho leva ao sucesso, o sucesso e meu tambem. 

Isso cria incentivos por parte do mentor para que seus orientandos tenham su¬ 
cesso. Tipicamente, sendo mais experiente e ja bem sucedida, uma pessoa em tal 
papel teria o respeito de uma significativa rede de pessoas. O mentor se torna um 
elo que reforija a conexao entre voce e sua rede. A importancia desse tipo de cone- 
xao nao pode ser subestimada. Afinal, a frase “Nao e o que voce sabe. E quem voce 
conhece” nao e um cliche sem motivo. 

O grau de formalidade num relacionamento de mentor nao e importante. Nin- 
guem precisa explicitamente pedir a alguem para ser seu mentor (embora nao seja 
definitivamente uma coisa ruim se voce o fizer). Na verdade, seu mentor pode nem 
saber que esta fazendo esse papel para voce. O que importa e que voce tenha alguem 
de confiaruja e que admire, que possa proporcionar uma orienta^ao a sua carreira e 
ajudar a afiar seu oficio. 
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Fa$a algo 

1) Tutorie a si mesmo - todos nos queremos ter alguem para nos orientar, mas a 
realidade e que nem sempre vamos poder encontrar alguem a quern possamos 
dar esse papel. Eis um jeito de fazer uma automentoria. 

Pense na pessoa de sua area que voce mais admira. Muitos de nos ja possuem 
uma pequena lista pronta, pegando de algum momento de nossas carreiras. Pode 
ser alguem com quern tenha trabalhado, ou pode ser alguem cujo trabalho e ad- 
mirado. Liste os dez atributos mais importantes desse modelo a seguir. Escolha 
os atributos que sao a razao de voce te-lo escolhido para esse papel. Tais atribu¬ 
tos podem ser de areas especificas de habilidade, como amplitude de tecnologia, 
ou a profundidade de conhecimento sobre algum dominio. Ou, eles podem ter 
caracteristicas mais pessoais, como a habilidade de deixar os membros da equipe 
tranquilos, ou a de ser um palestrante envolvente. 

Agora, ranqueie essas qualidades em ordem de importancia, sendo que 1 e o me- 
nos importante e 10, o mais importante. Voce acabou de criar e destilar uma lista 
de atributos que voce acha admiraveis e importantes. Esses sao os caminhos nos 
quais voce deve se empenhar para emular o modelo escolhido. Mas como esco- 
lher em qual focar primeiro? 

Adicione uma coluna a lista, e para cada item na lista, imagine como seu modelo 
iria avaliar voce em uma escala de 1 a 10 (10 sendo o melhor). Tente realmente 
se colocar na mente de seu modelo e observar a si mesmo como se fosse uma 
terceira pessoa. 

Quando voce tern os atributos, o ranking, e suas proprias avalia^oes, em uma co¬ 
luna final, subtraia sua classifica^ao em cada fileira do nivel de importancia que 
voce deu a coluna anterior. Se voce ranqueou algo como 10 para o atributo mais 
importante de seu modelo, e sua propria avalia^ao foi 3, isso lhe da uma priori- 
dade final de valor 7. Tendo preenchido esta coluna completamente, separando 
em ordem descendente, voce tera uma lista das 10 areas priorizadas em que voce 
deve melhorar. 

Comece com os primeiros dois ou tres itens, e formule uma lista de tarefas con- 
cretas que voce pode come^ar a fazer agora para melhorar a si mesmo. 
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Seja um mentor 


Se voce quer realmente aprender alguma coisa, tente ensina-la para outra pessoa. 
Nao tem jeito melhor de aperfei^oar seu entendimento de algo do que se forcjar a 
passa-lo para outras pessoas, para que eles possam entender. O simples ato de falar 
e um elixir conhecido para clarear a mente. Falar para bonecos e outros objetos 
inanimados e uma forma de resolver problemas bastante conhecida do folclore do 
desenvolvimento de software. 

Para descobrir se voce realmente sabe algo, tente ensinar para outra pessoa. 


Eu vi Martin Fowler dar uma palestra em uma sala de desenvolvedores em Ban¬ 
galore, na qual ele dizia que toda vez que ele realmente quer aprender algo, ele escreve 
sobre isso. Martin Fowler e um conhecido desenvolvedor de softwares e autor. Pode- 
mos dizer que ele e um dos mais bem conhecidos e influentes professores que essa 
industria tem a oferecer, se considerarmos que seu papel enquanto autor e aquele de 
um professor remoto e mentor. 
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Aprendemos ensinando. E ironico, porque esperamos que um professor ja saiba 
de tudo. Claro, eu nao quero dizer que podemos aprender completamente algo ensi¬ 
nando outra pessoa. Mas conhecer os fatos nao e o mesmo que entender suas causas 
e ramifica^oes. E o tipo de conhecimento mais profundo que desenvolvemos ao en- 
sinar a alguem. 

Procuramos analogias para explicar conceitos complexos, enquanto tentamos 
entender porque algumas analogias que parecem funcionar, na pratica nao funcio- 
nam. Ja outras que parecem menos efetivas, acabam sendo melhores. 

Quando voce ensina, voce precisa responder questoes nas quais voce pode nunca 
ter pensado. Por meio do ensino, nos limpamos os cantos sujos do nosso conheci¬ 
mento, que raramente sao expostos. 

Portanto, assim como voce pode se beneficiar encontrando um mentor, voce 
pode se beneficiar sendo um mentor para outra pessoa. 

Mentoria traz efeitos sociais positivos tambem. Um grupo de mentores e seus 
orientandos cria uma rede social firme e poderosa. A liga^ao mentor-orientando e 
bastante forte, de modo que os la^os dessa rede profissional seja mais forte do que 
aqueles relacionamentos passivos. Quando voce esta em uma rela^ao de mentoria 
com alguem, voce forma uma alian^a um com o outro. Uma rede desse tipo e um 
otimo lugar para fazer circular problemas dificeis ou procurar por trabalho. 

Voce tambem nao deveria subestimar que simplesmente faz sentir bem ajudar 
as pessoas. Se voce pode manter em mente os interesses de outros, tera realmente 
feito algo altruista com suas habilidades. No incerto ambiente economico de hoje, 
ajudar de fato alguem e um trabalho do qual voce nao pode ser demitido. E e pago 
com uma moeda que nao desvaloriza com infla^ao. 

Voce nao encontra um orientando saindo por ai e se autodeclarando um guru, 
mas sim sendo conhecido e disposto a compartilhar seu conhecimento paciente- 
mente. Nao se preocupe se voce nao e um expert absoluto em algum topico. As 
chances sao de que ha algo em que voce tern experiencia e que o qualificaria para 
ajudar alguem menos experiente. Encontre esse algo e comece a ser prestativo. 

Voce pode, por exemplo, ter feito uma consideravel quantidade de trabalhos em 
PHP. Voce poderia ir ate seu grupo local de usuarios PE 1 P e oferecer ajuda aos usua- 
rios menos experientes com seus problemas especificos. Ou, se voce nao tern um 
lugar disponivel para fornecer mentoria presencial, voce poderia simplesmente co- 
me^ar a responder perguntas em um forum de discussoes online ou em um canal 
IRC, ou ainda ajudar pessoas a fazer debug nos problemas de suas aplica^oes. Entre- 
tanto, mantenha em mente, que mentoria diz respeito a pessoas. Um relacionamento 
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de mentoria online nunca pode ser comparado ao que acontece entre dois seres hu- 
manos no mesmo local. 

Voce nao precisa montar um relacionamento de mentoria formal para obter esses 
beneficios. Apenas comece a ajudar pessoas, e o resto vira automaticamente. 

Fa$a algo 

1) Procure alguem para carregar sob suas asas. Voce pode encontrar alguem mais 
jovem e menos experiente em sua empresa, talvez um estagiario. Ou, voce po- 
deria conversar com os departamentos de ciencia da computa^ao ou sistemas de 
informa^ao em sua universidade local e se voluntariar para orientar um estudante 
da faculdade. 

2) Encontre um forum online e escolha um topico. Comece a ajudar. Torne-se co- 
nhecido por seu desejo e por sua habilidade de pacientemente ajudar pessoas a 
aprender. 
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Capitulo 15 

Pratique, pratique, pratique 


Quando eu estudava musica, eu passava longas noites no predio de musica da mi- 
nha universidade. Pelas finas paredes das salas de estudo da universidade, eu ficava 
imerso em algum dos sons musicais mais feios imaginaveis. Nao e que os musicos 
da minha escola eram ruins. Muito pelo contrario. Mas eles estavam praticando. 

Quando voce treina musica, ela nao deveria soar boa. Se voce sempre soa bem 
durante as sessoes de estudo, significa que voce nao esta estendendo seus limites. E 
para isso que serve a pratica. O mesmo e valido para os esportes. Atletas se esfor^am 
ate o limite durante os exercicios, de modo que eles possam expandir tais limites para 
as performances reais. Eles deixam a “feiura” acontecer nesse momento de pratica - 
e nao quando eles estao realmente trabalhando. 

Na industria da computa^ao, e comum encontrar desenvolvedores que for^aram 
seus limites. Infelizmente, esse e geralmente um caso de um desenvolvedor sendo 
subqualificado para as tarefas que ele assumiu. Nossa industria tende a praticar no 
emprego. Voce consegue imaginar um musico profissional subindo ao palco e re- 
plicando os sons inarticulados das salas de estudo da minha universidade? Isso nao 
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seria tolerado. Musicos sao pagos para apresentar em publico - nao para praticar. 
Similarmente, um lutador de artes marciais ou um boxeador estressando o-se ate a 
fadiga durante os combates nao iria muito longe no esporte. 

Como industria, nos devemos criar tempo para a pratica. Nos do ocidente fre- 
quentemente tomamos partido de programadores domesticos, baseados na quali- 
dade relativamente alta do codigo que eles produzem versus a de times offshore. Se 
vamos tentar competir com base na qualidade, temos que parar de tratar nosso em- 
prego como uma sessao de pratica. Temos que investir o tempo em nossa profissao. 

Muitos anos atras, eu comecei a experimentar exercicios de programa^ao mo- 
delada apos minhas sessoes de pratica de musica. A regra numero um era que o 
software que eu estava desenvolvendo nao poderia ser algo que eu desejava usar. Eu 
nao queria limpar os cantos na pressa, por conta de um objetivo final. Entao eu es- 
crevia softwares que nao eram uteis. 

Eu nao me preocupava com os cantos, mas estava frustrado ao descobrir que 
muitas das ideias que tive durante a pratica nao estavam funcionando. Embora eu 
estivesse tentando fazer tao bem quanto se fosse pra valer, na medida do possivel, os 
designs e codigos que eu criava nao eram tao elegantes quanto eu queria que fossem. 

Olhando para tras agora, vejo que o estranho sentimento que eu tive com essas 
experiences era um bom sinal. Meu codigo nao estava completamente desprovido 
de momentos brilhantes. Mas eu estava esticando meus musculos mentais e cons- 
truindo meus peda^os de codigo. Assim como para tocar o saxofone, se eu sentasse 
para praticar e so saissem sons bonitos, eu saberia que nao estava praticando. Da 
mesma forma, se eu sentasse para praticar os codigos e so viessem codigos elegan¬ 
tes, eu estaria provavelmente em algum lugar proximo ao centro das minhas atuais 
capacidades, em vez de no limite, aonde uma boa sessao de treinamento deveria me 
levar. 

Pratique nos seus limites. 


Portanto, como voce sabe o que praticar? O que estende seus limites? O assunto 
de como praticar poderia facilmente dar um livro so pra isso. Como um comedo, 
eu vou pegar emprestado mais uma vez da minha experiencia como um musico de 
jazz. Eu dividia o estudo de jazz nas seguintes categorias (simplificadas para os nao 
musicos): 

• Fisico / coordena^ao; 
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• Leitura a primeira vista; 

• Improvisa^ao; 

Isso deve servir como um quadro de uma das maneiras de como um desenvol- 
vedor deve praticar. 

Fisico / coordenacao: musicos devem praticar os aspectos tecnicos de seus ins- 
trumentos. Produ^ao de som, coordenacao fisica (fazer os dedos se moverem com 
agilidade, por exemplo), velocidade e precisao. Tudo isso e importante. 

O que nos, desenvolvedores de software, temos desses fundamentos de musica? 
E quanto aos cantos sujos de sua primeira linguagem de programa^ao que voce rara- 
mente visita? Por exemplo, a linguagem que voce usa suporta expressoes regulares? 
Expressoes regulares sao um recurso extremamente poderoso e subutilizado de mui- 
tos ambientes de program a^ao. A maioria dos desenvolvedores nao as usa quando 
poderia, porque nao possui o nivel de habilidade necessario para serem produtivos 
com elas. Como resultado, um monte de codigo de manipula^ao de strings e criado 
e, portanto, exige maior manuten^ao. 

As mesmas regras se aplicam para as APIs de sua linguagem. Se voce nao tiver as 
varias ferramentas do ambiente sob seus dedos (como dizem os musicos), e pouco 
provavel que voce as use quando elas realmente o poderiam ajudar. Tente verdadei- 
ramente mergulhar em, por exemplo, como programa^ao multi-threaded funciona 
na sua linguagem. Ou, e quanto as bibliotecas, APIs pra programar aplicaijoes em 
rede, ou mesmo o grupo de funcionalidades disponiveis para trabalhar com cole- 
Coes ou listas? A maioria das linguagens de programacao modernas oferece ricas e 
poderosas bibliotecas em todas essas areas, mas desenvolvedores tendem a apren- 
der uma pequena parcela, com a qual eles podem, menos eficientemente, escrever o 
mesmo codigo que eles teriam escrito se tivessem dominado o todo o conjunto de 
ferramentas. 

Leitura a primeira vista: especialmente como um musico de estudio, a habili¬ 
dade de ler e executar musica quase perfeitamente na primeira tentativa e suprema 
para um profissional. Uma vez eu toquei saxofone em um jingle para a Blockbuster 
(a videolocadora). Eu toquei ambas as partes principals e secundaria de saxofone 
alto em uma musica que tinha um ritmo bem rapido. Quando a fita comecou a to- 
car, era a primeira vez que eu via aquela musica. Tocamos uma vez a parte principal 
e outra a parte secundaria. Qualquer erro, e a banda inteira teria de fazer tudo de 
novo - e isso aumentaria o custo de horas no estudio. 
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Para desenvolvedores, o que significaria ser capaz de ler um codigo ao ve-lo? Ou 
especifica^oes de requisitos ou designs? Um excelente lugar para encontrar novos 
codigos com os quais praticar e a comunidade open-source. Voce tern algum biblio- 
teca open-source de que goste? E se voce tentar adicionar uma nova funcionalidade 
nela? Va procurar na lista de tarefas a fazer dessa biblioteca, e force a si mesmo a 
dedicar uma consideravel parcela de tempo para implementar isso (ou, pelo menos, 
determinar o que e necessario para implementa-la). 

Depois de escolher uma biblioteca, baixe seu codigo-fonte, e comece a explorar. 
Como voce sabe onde procurar? Quais truques voce usa para se achar em uma base 
de codigo relativamente grande? Por onde come^a? 

Esse e um exercicio que voce pode fazer com frequencia e em curtos periodos 
de tempo. Voce nao necessariamente deve implementar a funcionalidade. Apenas 
a use como um ponto de partida. O verdadeiro objetivo e entender o que voce esta 
visualizando o mais rapido possivel. Certifique-se de variar os softwares com os quais 
voce trabalha. Tente diferentes tipos de software em diferentes estilos e linguagens. 
Anote os pontos que facilitam ou dificultam a voce se encontrar no codigo. Quais 
padroes voce esta desenvolvendo que o ajudam a trabalhar no codigo? Quais rastros 
voce deixa para si mesmo para o ajudar a navegar conforme voce sobe ou desce nas 
camadas dessa funcionalidade? 

Improvisacao: improvisa^ao e pegar alguma estrutura ou restri^ao e criar algo 
novo, em tempo real, sobre essa estrutura. Como programador, eu me descobri fa- 
zendo mais improvisos em momentos de estresse. “Oh nao! O servidor da rede 
sem fio caiu, e nos estamos perdendo pedidos!” E ai que algumas das mais criativas 
improvisaijoes acontecem. E ai que voce faz coisas loucas, como recuperar dados 
perdidos manualmente resubmetendo pacotes sobre uma rede sem fio a partir de 
um arquivo binario. Ninguem o pediu pra fazer essas coisas, especialmente nao no 
calor do momento. Esse tipo de habilidade de programa^ao afiada e rapida pode ser 
como um poder magico quando usada no momento certo. 

Uma otima maneira de afiar a mente e melhorar suas habilidades de improvisar 
codigos e praticar com restri^oes autoimpostas. Pegue um simples programa, e tente 
escreve-lo com essas restrfipoes. Meu exercicio favorito e escrever um programa que 
mostra a letra da velha can^ao “99 Bottles of Beer on the Wall”. Como voce pode- 
ria escrever tal programa sem atribuir variaveis? Ou, o quao curto voce consegue 
escrever o programa, de modo que ele ainda exiba a letra corretamente? Para uma 
restri^ao adicional, quao rapido voce pode escrever esse programa? Que tal praticar 
problemas pequenos e dificeis com um timer ? 
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Essa e apenas uma perspectiva limitada sobre como praticar. Voce pode pegar 
exemplos de qualquer area, das artes visuais ate pratica de religiao. O que importa e 
encontrar suas proprias necessidades e certificar-se de que voce nao esta praticando 
durante suas apresenta^oes (no emprego). Voce deve reservar um momento para 
praticar. E sua responsabilidade. 

Fa£a algo 

1) TopCoder - http://topcoder.com e um renomado site de competiijao de progra- 
ma^ao. Voce pode registrar uma conta e competir online por premios. Mesmo se 
voce nao se interessa em competir com outros, o TopCoder oferece uma sala de 
treinamento com uma grande coleijao de exercicios que podem ser usados como 
uma excelente base para suas sessoes de estudo. Va se registrar e faqa uma tenta- 
tiva. 

2) Code Kata - Dave Thomas, um dos Pragmatic Programmers (o editor deste livro 
no original), transformou a ideia de praticar codigo em algo... bem, pragmatico. 
Ele criou uma serie do que ele chama de Code Kata, que sao pequenos exercicios 
que estimulam o pensamento que os programadores podem fazer na linguagem 
de sua escolha. Cada kata enfatiza uma tecnica especifica ou processo de pensa¬ 
mento, provocando uma flexao concreta de seus musculos mentais. 

No blog http://codekata.pragprog.com, Dave disponibiliza gratuitamente diver- 
sos katas. La, voce tambem encontra links para uma lista de e-mail e para as 
solu^oes de outros usuarios, junto da discussao sobre como foram resolvidos. 

Seu desafio: trabalhe com os katas. Mantenha um diario (ou talvez um blog) 
das suas experiencias com eles. Quando terminar, escreva seu proprio kata e 
compartilhe. 
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O jeito que voce faz 


“Desenvolver software” nao e uma coisa, um substantivo. Do contrario, “desenvolver 
software” e um termo; e o processo de criar uma coisa. Quando estamos codificando, 
e tao importante focar no processo utilizado quanto focar no produto que esta sendo 
desenvolvido. Se voce tirar os olhos do processo, estara arriscando entregar atrasado, 
ou entregar o produto errado, ou mesmo nao entregar. Esses resultados tendem a ser 
desprezados pelos clientes. 

Felizmente, muita aten^ao tern sido dada ao processo de criar um bom software 
(e produtos em geral). Muito dessas tecnicas foram catalogadas em um grupo de 
metodologias, que sao tema de varios livros. 

Infelizmente, a maioria dos desenvolvedores nao se beneficia dessa boa informa- 
^ao. Para a maior parte das equipes, o processo e uma reflexao tardia ou algo imposto 
de cima. O termo metodologia, em suas mentes, se tornou sinonimo de papelada e 
longas e insignificantes reunioes. Muito frequentemente, a metodologia e algo que 
seus chefes impoem. 

Os gerentes intuitivamente sabem, que eles precisam seguir algum tipo de pro- 
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cesso, mas geralmente nao sabem sobre as op^oes que agora estao disponiveis. Como 
resultado, eles tiram a poeira dos mesmos processos que lhes foram impostos na de- 
cada de 80, os envolvem com uma fita de chavoes compativeis (a fita com tons pasteis 
Agile e uma boa escolha nesse momenta), e passam a pratica para seus times. E, ao 
menos que alguem quebre o ciclo realmente pesquisando o que funciona e o que nao, 
o mesmo processo acontecera outras vezes, conforme os desenvolvedores da equipe 
tornam-se gerentes. 

Talvez voce esteja pensando que deve existir um jeito melhor de desenvolver 
software. E para a maioria das equipes, existe. 

Se voce e um programador, testador, ou designer de software, voce pode pensar 
que o processo do desenvolvimento nao e sua responsabilidade. Infelizmente, geral¬ 
mente nao e responsabilidade de ninguem. Se for designado a alguem, pode cair no 
buraco negro, tambem conhecido como “grupo de processo”. A verdade e que, para 
um processo de software ter alguma chance de ser implementado com sucesso, ele 
deve ser compreendido pelas pessoas que o estao usando - pessoas como voce. 

A melhor maneira de compreender e dominar esses processos e ajudar a 
implementa-los. Se sua empresa nao possui um processo, pesquise metodologias 
que podem funcionar para voces. Tenha almo^os com sua equipe para discutir os 
atuais problemas de desenvolvimento, e sugira que adotar um processo padrao pode 
mitiga-los. Reuna um piano de colocar em a^ao o processo escolhido na sua empresa 
e obtenha a aprova^ao de todos. Entao comece a implementar seu piano. 

Se voce quer sentir que e dono de um processo, ajude a implementa-lo. 


Alternativamente, voce talvez trabalhe em um ambiente em que o processo e 
passado de cima para baixo. No momento em que as ideias chegam ao time de de¬ 
senvolvimento, as praticas foram diluidas e reinterpretadas, ate o ponto em que se 
tornam irreconheciveis das originais. Lembra-se da brincadeira de telefone-sem-fio? 

Mais uma vez, essa e uma oportunidade de tomar a iniciativa. Pesquise a meto- 
dologia que introduziram, e ajude a interpretar o que ela realmente significa, tanto 
para seu time como para sua gerencia. Voce nao podera contestar que um processo 
foi imposto, entao voce deve faze-lo funcionar fazendo o correto. 

O mundo da metodologia pode rapidamente come^ar a parecer uma concha oca 
de chavoes. Mas, como podem ser chavoes compativeis, voce sempre pode apren- 
der alguma coisa do estudo de um processo de software - mesmo se essa coisa e o 
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que nao fazer. Se voce entender bem do processo de software, podera fazer uma 
argumenta<to mais confiavel sobre como sua equipe deveria estar trabalhando. 

Mesmo com a abundancia de metodologias para escolher, e bem dificil que voce 
trabalhe para uma empresa que implemente uma delas inteiramente. Tudo bem. O 
melhor processo a se seguir e o que torna sua equipe mais produtiva e que resulta 
em melhores produtos. 


Metodologias: nao so para geeks 

Embora o gerenciamento de projetos nao seja necessariamente ligado 
a metodologia de desenvolvimento de software, voce pode dar de cara 
com as tecnicas de gerenciamento de projetos da sua empresa. Numero- 
sas metodologias de gerenciamento de projetos estao em uso por toda in- 
dustria de tecnologia. Provavelmente, o mais notavel e o Project Manage¬ 
ment Book of Knowledge (http://www.pmi.org) , do Project Management 
Institute, com seu programa de certificate, que e bastante reconhecido. 

Six Sigma (http://www.isixsigma.com) e outra metodologia de qua- 
lidade nao especifica de software. Dirigida por empresas como General 
Electric e Motorola, a abordagem da Six Sigma enfatiza a medi^ao e a 
analise dos processos e produtos para conduzir a satisfaijao do cliente e a 
eficiencia. Embora nao sejam especificas para desenvolvimento de soft¬ 
ware, a abordagem rigorosa e metodica da Six Sigma oferece varias li^oes 
que sao diretamente aplicaveis a sua fumjao como programador. 

O unico modo de descobrir essa epifania reveladora e estudar as op^oes dispo- 
niveis, escolher as peijas que fazem sentido para voce e sua equipe, e continuamente 
refina-las baseando-se nas suas experiences. 

Em ultimo caso, se voce nao pode implantar o processo, voce nao consegue fazer 
o produto. E muito mais facil encontrar alguem que pode fazer o software funcionar 
do que encontrar alguem que faija o making of do software funcionar. Portanto, adi- 
cionar conhecimento do processo de desenvolvimento de software para seu arsenal 
apenas vai ajuda-lo. 

Fa£a algo 

1) Escolha uma metodologia de desenvolvimento de software, e escolha um livro, 
comece a ler sites e inscreva-se em uma lista de e-mails. Olhe para a metodologia 
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com um olho critico. Quais voce acha que seriam seus pontos fortes e fracos? 
Em seguida, fa^a o mesmo para outra metodologia. Contraste suas vantagens e 
desvantagens. Como voce poderia combinar suas abordagens? 
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Nos ombros dos gigantes 


Quando eu tocava jazz, eu ficava muito tempo ouvindo musica. Eu nao apenas co- 
locava musica de fundo enquanto eu lia ou dirigia. Eu realmente ouvia a musica. Se 
a improvisa^ao no jazz significa executar o que voce escuta por cima dos acordes de 
uma musica, entao realmente ouvir a musica e uma fonte de inspirac^ao e conheci- 
mento do que funciona e do que nao. O que soa otimo e apenas o que se encaixa 
la. 

A enorme historia do jazz serve como uma incrivel fonte de conhecimento, para 
qualquer um com a habilidade de ouvi-las. Ouvir musica, portanto, nao e uma ati- 
vidade passiva para um musico de jazz. E um estudo. Mais ainda, a habilidade de 
entender o que voce esta ouvindo e uma proficiencia que se desenvolve ao longo do 
tempo. Meu circulo de amigos musicos realmente faziam esse tipo de audi^ao expli- 
citamente. Tinhamos festas para ouvir musicas, em que um grupo de musicos geeks 
de jazz se sentavam e ouviam musica, para depois discuti-la. As vezes, jogavamos 
“Nomeie o improvisador”, no qual um de nos tocava uma grava^ao de um solo im- 
provisado e o resto deveria adivinhar, baseado no estilo, quern havia gravado aquele 
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improviso. 

Nos do mundo do jazz nao eramos especiais, claro. Compositores de musica 
erudita fazem a mesma coisa. Assim como romancistas e poetas. Assim como escul- 
tores e pintores. Estudar a obra dos mestre e uma parte essencial para se tornar um 
mestre. 

Quando ouviamos as gravacjoes de jazz, discuti'amos os artificios musicais que 
os improvisadores usavam para comunicar seus pontos musicais. “Uau! Voce ouviu 
como ele come^ou contornando no final da estrutura?” ou “Foi realmente estranho 
o jeito que ele estava tocando atras do compasso”. Essas discussoes nos ajudavam 
a investigar e descobrir truques que podiamos levar para tentar na nossa proxima 
sessao de improvisa<;ao. 

Minere os codigos existentes para ter insights. 


Design de software e programaijao tern muito em comum com as artes, guarda- 
das as devidas particularidades. Podemos investigar uma base de codigo grande para 
encontrar padroes e truques. O movimento dos design patterns (veja Design Patterns 
[3]) e focado na descoberta e na documenta^ao de solu^oes reusaveis para problemas 
comuns de desenvolvimento de software. Design patterns formalizaram o estudo de 
codigos existentes, tornando a pratica acessivel a um grande numero de profissionais 
de software. Ainda assim, eles abrangem apenas um pequeno subconjunto dos tipos 
de tecnicas que podemos aprender atraves da leitura de codigo. 

Como outros programadores resolvem problemas? Como outros usam estrategi- 
camente variaveis, fun (joes e nomenclatura? Se eu quisesse implementar o protocolo 
Jabber, como eu poderia faze-lo? Quais maneiras criativas eu poderia achar para li- 
dar com a comunicaijao entre processos, entre UNIX e sistemas Windows? Esses sao 
o tipo de questoes que voce pode responder atraves do estudo de codigos existentes. 

Use codigo existente para refletir sobre suas proprias capacidades. 


Ainda mais importante que encontrar soluijoes para problemas especificos e o 
uso de codigos de outros desenvolvedores como uma lente de aumento para inspe- 
cionar nossos proprios estilos e capacidades. Assim como escutar uma gravaijao de 
John Coltrane sempre me lembrava de onde eu me estava na escala de habilidades 
de um saxofonista; ler o codigo de um otimo desenvolvedor possui um efeito humi- 
lhante. Entretanto, nao se trata apenas de se sentir humilhado. Conforme voce le 
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o codigo, voce encontrara coisas que nunca teria feito. Encontrara coisas que voce 
pode nunca ter imaginado. Por que? Em que o desenvolvedor estava pensando? 
Quais foram suas motivates? Voce pode ate aprender com codigos ruins neste tipo 
de explora^ao critica de autoconhecimento a partir do trabalho de alguem. 

O ato de aprender a partir do trabalho que veio antes de voce funciona bem no 
mundo das artes, porque nao ha recursos escondidos para uma pintura ou uma pe^a 
de musica. Se voce pode ouvir a musica ou ver a obra de arte, voce pode aprender 
dela. Felizmente, como desenvolvedores de software, temos acesso a praticamente 
uma infinita serie de softwares existentes no mundo open source. 

Ha tantos open sources disponiveis que seria impossivel realmente ler todos. De- 
finitivamente ha projetos open source ruins, mas tambem ha alguns otimos. Existe 
codigo open source disponivel para implementar quase qualquer tarefa que pode ser 
feita com software em quase todas as linguagens de programa^ao disponiveis. 

Conforme voce olha para esse codigo com um olhar critico, voce come^a a de- 
senvolver seus proprios gostos, assim como seria com musica, arte ou literatura. Di- 
versos estilos e artificios vao entrete-lo, impressiona-lo, deixa-lo bravo, e (eu espero) 
desafia-lo. Se voce realmente estiver procurando por eles, encontrara algum truque 
que o torne mais produtivo com rela^ao a paradigmas de design, mudando comple- 
tamente o jeito como voce resolve problemas. Assim como nas artes, estudando e 
aprendendo com os habitos dos outros, voce desenvolvera seu proprio estilo distin- 
tivo de desenvolvimento de software. 

Um efeito colateral positivo de leitura de codigo e que voce vai aprender mais 
sobre o que ja existe. Quando voce tern um novo problema que precisa de solu^ao, 
voce deve se lembrar que “Oh, eu vi uma biblioteca que faz manipula^ao de MIME 
naqueles projetos”. Se os termos de licen^a estao certos, voce pode economizar bas- 
tante tempo, e sua empresa, bastante dinheiro, ao se tornar mais ciente do que ja 
esta la fora para ser usado. Voce pode se surpreender ao perceber quanto dinheiro e 
gasto na industria de software para reimplementar a roda (invencao seria uma pala- 
vra muito generosa) mais e mais vezes. 

Sir Isaac Newton disse: “Se vi mais longe, foi porque eu subi nos ombros dos gi¬ 
gantes”. Pessoas espertas como Newton sabem que ha muito o que aprender daqueles 
que vieram antes de nos. Seja como Newton. 

Fa$a algo 

1) Escolha um projeto e o leia como um livro. Fa^a anota^oes. Esboce as coisas boas 
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e ruins. Escreva uma critica e a publique. Ache pelo menos um truque ou padrao 
dele que voce possa usar. Encontre pelo menos uma coisa ruim que voce obser- 
vou que acrescentara a sua lista do que naofazer quando estiver desenvolvendo 
software. 

2) Encontre um grupo de pessoas com a mentalidade parecida com a sua e se retina 
com eles uma vez por mes. A cada sessao alguem indica algum trecho de codigo 
para ser estudado, de 2 a 200 linhas. Quebre o codigo e discuta o que esta por 
tras dele. Pense nas decisoes que levaram a ele. Pondere sobre o codigo que nao 
esta la. 
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Capitulo 18 

Automatize-se em um emprego 


Um assunto constante na minha carreira tem sido o conflito entre o desejo das areas 
gerenciais de TI em contratar empresas de consultoria com baixo custo (geralmente 
offshore) para fazer o trabalho e minha forte cren^a de que o desenvolvedor mais 
barato geralmente nao leva a um custo mais baixo. Eu ja tive varias conversas ten- 
sas com diretores e vice-presidentes, argumentando de forma apaixonada sobre as 
vantagens de contratar poucos desenvolvedores que sejam realmente bons em vez de 
uma legiao de pessoas de baixo custo e de habilidades fracas. 

Infelizmente, em geral eu era interrompido no meio da minha argumenta^ao. O 
problema da minha posi^ao nao e que eu estava errado (obviamente!). E que nao 
ha uma maneira facil de provar que estava certo. E, a partir de uma perspectiva de 
custo, a unica evidencia concreta que temos leva a conclusao de que um baixo custo 
por hora e, de fato, vantajoso para a empresa. 

Imagine um projeto de software hipotetico para algum dominio que vier a sua 
mente. Quantos programadores sao necessarios para escrever um software como 
este em tres meses? Cinco, voce diz? Seis? OK, e quanto ao mesmo projeto em dois 
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meses? Como voce diminui um mes? 

O gerenciamento padrao de TI diz que voce adiciona programadores para ir mais 
rapido. £ errado, mas e nisso que as pessoas acreditam. E se voce consegue fazer um 
projeto simples ir mais rapido ao adicionar programadores, a conclusao desta regra 
e a de que mais gente significa maior produtividade. Mas ha mais de uma maneira 
de conseguir isso. Se a meta e aumentar a taxa de desenvolvimento de software, voce 
pode: 


• Conseguir pessoas mais rapidas para fazer o trabalho; 

• Conseguir mais pessoas para fazer o trabalho, ou; 

• Automatizar o trabalho. 

Uma vez que ainda nao se sabe como verdadeiramente medir a produtividade 
de desenvolvimento de software, e dificil provar que uma pessoa e mais rapida que 
outra. Entao, gerentes de Ananias se focam no custo por hora. 

Isso leva a uma simples formula, que assume um periodo de tempo fixo: 

Numero de projetos 

Produtividade = - 

Numero de programadores x Taxa hor^ria 


Em alguns ambientes, e realmente possivel calcular a produtividade real de um 
time de software. Na maior parte, voce vai encontrar medidas maleaveis e amorfas 
como numero de projetos ou numero de requerimentos, sem nenhuma possibili- 
dade de repetir a medi^ao dessas unidades. 

Logo, a abordagem do programador mais rapido e muito dificil de se provar, 
e nos nao queremos encorajar a abordagem de se adicionar mais programadores 
baratos. Isso nos leva a uma automaijao. 

Eu me lembro do sensacionalismo em rela<;ao a perda de emprego nos Estados 
Unidos na decada de 80. Naquela epoca, nao apenas estavamos culpando outros 
paises, mas tambem culpavamos as maquinas e, especificamente, computadores. Gi- 
gantescos bravos robotizados estavam sendo instalados em industrias. Eles podiam 
bater o trabalho dos humanos tanto em rendimento quanto em precisao, o que indica 
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que nem valia a pena compara-los. Todo mundo estava chateado — todo mundo, isto 
e, com excegao das pessoas que criaram os bravos robotizados. 

Imagine que sua empresa seja do ramo de criagao de websites para pequenas em- 
presas. Voce basicamente precisa criar o mesmo site repetidas vezes, com contatos, 
pesquisas, carrinhos de compra, os servigos. Ou voce poderia contratar um pequeno 
numero de programadores realmente rapidos para construirem os sites para voce, 
ou contratar varios programadores com custo baixo para fazer a coisa toda manual- 
mente e repetitivamente, ou, em vez, criar um sistema para gerar os sites. 

Se colocarmos alguns numeros (inventados) na formula do gerente de finangas, 
temos as equates mostradas na Figura 18.1. 

Automagao faz parte do DNA de nossa industria. Ainda assim, por alguma ra- 
zao, tendemos a nao automatizar nosso trabalho. Como voce poderia comprovada- 
mente fazer softwares melhores, mais rapidos e mais baratos do que seu concorrente 
offshore? Faga os robos; Automatize-se em um emprego. 


Programadores rapidos 


- = 0,02 

3 x $80 


Programadores baratos 

5 

- = 0,02 

20 x $12 

Um programador + 
um brago robbtico 

5 

- = 0,06 

1 x $80 


Figura 18.1: Comparagao de produtividade 


De consultor de TI para diretor administrative 

por Vik Chadha 

Minha jornada de deixar de ser um consultor de TI na GE para ser empresario 
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na bCatalyst (um aceleradora de negocios com um capital de 5 milhoes de dolares) 
nao foi um caminho que eu tinha pensado como o proximo passo de minha carreira. 

Entao, como foi que eu fiz a transiijao de trabalhar para uma das 5 principals 
empresas no ranking da revista Fortune, com dezenas de milhares de funcionarios, 
para trabalhar em uma empresa que orientava e investia em startups de tecnologia 
em estagio inicial? Quando eu olho para tras e tento ligar os pontos, alguns padroes 
importantes emergem, e eu gostaria de compartilha-los com voce, com a esperan^a 
de que voce possa adapta-los para o seu contexto. 

Logo depois de terminar meu mestrado em engenharia da computa^ao e eletrica 
na Virginia Tech, eu entrei na GE como um consultor. O uso comercial da internet 
estava comecymdo a avarujar em passos largos, e eu trabalhei em varios projetos para 
fazer a plataforma mais incrlvel e poderosa, junto de suas tecnologias internas, pro- 
gredindo rapidamente come^ando pela equipe de finan^as de TI, passando para o 
grupo de serviijos e tecnologia, para a automa^ao de vendas, e finalmente, para os 
dados de venda do grupo de deposito, trabalhando em cada equipe para desenvolver 
novas iniciativas. Eu adorava pesquisar, e com isso, pegar as mais novas tecnologias 
e aplica-las para resolver problemas complicados. 

Entretanto, viver nessa area de novidades da tecnologia nem sempre era diver- 
tido. Nos invariavelmente tinhamos problemas com tecnologias que ainda nao es- 
tavam prontas para serem usadas, e gastavamos muito tempo e energia ajudando os 
seus donos a debugarem seus produtos. Do ponto de vista do cliente, eu aprendi 
que nao importa quao legal a tecnologia seja, ela so tera valor se resolver um pro- 
blema real. Ao longo do tempo, isso me ajudou a mudar a maneira de pensar, de ser 
centrado em tecnologia para ser centrado em solu^ao. Perceber essa nova forma de 
pensar foi muito valioso para avaliar as startups de tecnologia em estagio inicial na 
bCatalyst, alguns anos depois. 

Contudo, por mais que eu gostasse de trabalhar na GE, um aspecto importante 
estava faltando. Eu senti que, na minha fun^ao como um profissional de TI, eu estava 
basicamente desenvolvendo todas minhas habilidades em uma unica dimensao, sem 
ter a oportunidade de realmente entender como as empresas funcionam, como elas 
fazem dinheiro, o que as tornam sustentaveis, e como elas inovam. Em vez de hear 
frustrado, eu decidi tomar a iniciativa e fazer algo a respeito disso, aprendendo mais 
sobre negocios e empreendedorismo. Eu nunca fiz nenhum curso de negocios e sabia 
que o unico jeito para eu aprender os detalhes do que e preciso para come^ar uma 
empresa era colocando a mao na massa (isto e, aprender por meio de tentativas e 
erros). 
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Um ex-colega de quarto e empreendedor, que tambem era um amigo proximo 
(Raj Hajela), minha esposa (Vidya), e eu elaboravamos ideias tentando descobrir 
onde havia necessidades insatisfeitas no mercado. Nos queriamos explorar as opor- 
tunidades de e-commerce, mas nao queriamos vender nada que fosse uma mercado- 
ria. Nos tinhamos um interesse real, e um conhecimento previo em artes e gostava- 
mos do fato de que cada obra de arte era unica em sua natureza. Meu tio durante 
a vida toda foi um artista que lutou para se sustentar com isso. Fizemos algumas 
pesquisas e concluimos que este era o caso da maioria dos artistas. Entao decidimos 
resolver esse problema criando uma plataforma que ajudasse os artistas para que pu- 
dessem publicar e promover seus trabalhos, alem de manter contato com seus con- 
sumidores. Com essa missao em mente, lan^amos o Passi0n4Art.com e come^amos 
o trabalho pesado de conseguir artistas para se juntarem ao nosso site e colocarem as 
imagens digitais de suas pinturas online. Depois que inscrevemos os primeiros 1000 
artistas, e eles conseguiram montar seus proprios websites, acreditamos que estava- 
mos dando alguma coisa de valor, e passamos a procurar por investimento externo. 

Naquela epoca (cerca de 1999), uma empresa chamada eMazing.com fornecia 
dicas diarias sobre uma variedade de assuntos, e nos achamos que podiamos fazer 
parceria com eles (trabalhando com nossos artistas e o canal de distribui^ao deles), 
para fornecer um Art Tip of the Day (dica de arte do dia). Um dos chefes executivos 
se reuniu conosco, aprovou o que tinhamos a oferecer e concordou em fazer uma 
tentativa. 

Falamos pra ele que estavamos procurando investimento para construir nossa 
infraestrutura, e ele gentilmente se encarregou de enviar nosso piano de negocios 
para um novo acelerador de negocios na cidade, chamado bCatalyst. 

Poucos dias depois, recebemos uma liga^ao de Keith Williams, o CEO da bCa¬ 
talyst, informando-nos que eles tinham interesse em nos encontrar pessoalmente 
e saber mais sobre nossas inten^oes. Estavamos obviamente empolgados com essa 
reuniao. Eu nao percebi ate muito tempo depois o quao importante era o fato de eles 
terem ouvido sobre nos de uma fonte confiavel. A liqao aqui e que se voce precisar 
entrar em contato com um investidor de risco, trabalhe duro para conseguir uma 
boa indica^ao, ja que esta e a melhor maneira de abrir portas. 

Ao longo das varias reunioes que tivemos com Keith, percebemos que havia uma 
boa quimica entre nossos times, mas a bolha da internet havia recentemente estou- 
rado, e o momento nao era bom para eles fazerem um investimento nessa area. Con- 
tudo, eles nos disseram que se trouxessemos outra ideia da qual eles gostassem, nao 
hesitariam em nos apoiar. Eu perguntei-lhes se essa era uma maneira educada de 
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se dizer “nao” ou se eles estavam falando serio sobre trabalhar conosco. Eles nos 
garantiram que realmente estavam interessados. 

Entao eu pedi outra reuniao com Keith e disse que eu estava disposto a sair da GE 
para trabalhar com eles em periodo integral nos proximos meses e explorar outras 
oportunidades de startup. Essa oportunidade se materializou porque eu consegui 
convence-los de que eu estava disposto a colocar minha propria pele na jogada, uma 
vez que eu havia deixado a GE sem um caminho claro e seguro diante de mim. 

Durante os proximos 12 meses, todo dia nos nos encontravamos com equipes 
diferentes, selecionando suas ideias, e eu reparei em um novo padrao no conjunto 
de questoes que perguntavamos a cada empresa. 

Eu compilei essa lista e estou compartilhando as questoes com voce, no caso 
de voce precisar arrecadar dinheiro de investidores de risco no futuro; veja http: 
//www.greaterlouisville.com/EnterpriseCORP/Forms/BusinessAssessment/. 

As habilidades que eu adquiri durante aquele ano na bCatalyst me levaram ao 
meu emprego atual, como diretor administrative da Enterprise Corp. Nos ultimos 
sete anos, eu trabalhei com mais de 100 empresas e ajudei a arrecadar um fundo de 
mais de 75 milhoes de dolares. Essa tern sido uma experiencia extremamente satis- 
fatoria, que nao teria sido possivel se eu nao tivesse tornado a iniciativa e sido aven- 
tureiro em tentar coisas novas. Os varios zig-zags ao longo do caminho foram parte 
integral do processo. Minha esperamja e de que voce, leitor, use minha historia para 
se inspirar a encontrar seu proprio caminho, aquele que vai usar suas habilidades ao 
maximo. 

Vik Chadha e 0 diretor administrativo da Enterprise Corp. 

Fa^a algo 

1) Escolha uma tarefa que voce normalmente faz de forma repetitiva e escreva um 
gerador de codigo para ela. Nao se preocupe com reusabilidade. Apenas garanta 
que seu gerador economize tempo. 

Pense em uma maneira de aumentar o nivel de abstraijao do que voce esta ge- 
rando. 

2) Pesquise por model-driven architecture (MDA — Arquitetura orientada a mo- 
delo). Experimente algumas das ferramentas disponiveis. Procure algum lugar 
do seu trabalho no qual aplicar alguns conceitos de MDA, ou talvez o grupo com¬ 
plete de ferramentas. Pense em aplicar os conceitos de MDA apenas com as fer¬ 
ramentas que voce utiliza todo dia. 
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Capitulo 19 

Agora mesmo 


Imagine que voce esta em uma corrida com um premio de $100000. Vence a pri- 
meira equipe que criar um software para implementar uma aplica^ao de contas a 
receber. Voce e sua equipe se inscreveram para competir. O concurso vai acontecer 
em uma semana. Para ganhar, seu codigo deve ser completamente testado e imple¬ 
mentar um conjunto minimo de funcionalidades. Voce come^a sabado de manha, 
e tern ate segunda-feira de manha para completar sua aplica^ao. A primeira equipe 
que concluir antes de segunda de manha ganha a corrida. Se nenhum time terminar 
antes disso, o que tiver mais funcionalidades implementadas vence. 

Voce folheia os requisites das fun^oes da aplica^ao. Olhando para a lista de fun- 
cionalidades, voce percebe que o sistema e semelhante em tamanho e escopo a varios 
sistemas com que voce trabalhou no passado. Enquanto o objetivo acordado em sua 
equipe e terminar no meio do dia de domingo, por um momento voce come^a a se 
questionar. Como e que uma aplicacao de escopo similar aquelas nas quais pas- 
samos semanas trabalhando no escritorio vai ser conduida em um unico final de 
semana? 
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Mas com o comedo da competi^ao voce come^a a codificar e percebe que sua 
equipe vai ser capaz de alcan^ar o objetivo. A time esta em um movimento coletivo, 
produzindo recurso depois de recurso, consertando erros, tomando decisoes em fra¬ 
mes de segundo, e concluindo as funcionalidades. Voce se sente bem. Em revisoes 
de projeto e reunifies de status la na sua empresa, voce sonhava pegar uma pequena 
equipe, tirar daquele ambiente burocratico para se dedicar a criaijao de uma nova 
aplica^ao em tempo recorde. 

Muitos de nos tern esse sonho. Sabemos que nossos processos nos atrasam. Nao 
apenas isso, mas sabemos que a velocidade de nossos ambientes nos faz ir mais de- 
vagar. 

O quepodemos fazer? Agora mesmo? 


A lei de Parkinson afirma que “O trabalho se expande ate preencher o tempo 
disponivel em sua completude”. O lado triste e que, mesmo quando voce nao quer 
que seja desse jeito, voce pode cair na armadilha, especialmente quando existem 
tarefas que voce nao quer fazer. 

No caso de uma corrida para implementar um sistema em um final de semana, 
voce nao tern tempo de deixar as tarefas de lado, entao voce nao o faz. Voce nao pode 
atrasar uma decisao, entao voce nao o faz. Voce nao pode evitar trabalho chato, e 
voce sabe que deve faze-lo tao rapido que nada pode ser tao chato. 

A lei de Parkinson e uma observa^ao empirica — e nao um mandato humano 
inescapavel. Um senso de urgencia, mesmo manufaturado, e suficiente para facil- 
mente dobrar ou triplicar sua produtividade. Tente isso, e voce vera. Voce pode fazer 
mais rapido. Voce pode fazer agora. Voce pode torna-lo pronto em vez de conversar 
sobre torna-lo pronto. 

Se voce tratar seus projetos como uma corrida, voce chegara ao final muito mais 
rapido do que se voce trata-los como uma cela de prisao. Crie movimento. Seja 
aquele que empurra. Nao fique confortavel demais. 

Sempre seja aquele que pergunta “Mas o que pode ser feito agora mesmo?” 

Fa 9 a algo 

1) Olhe para sua escrivaninha. Examine as tarefas que estao la por um longo tempo, 
os projetos que estao come^ando a tomar forma, ou aqueles em que voce esta um 
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Capitulo 19. Agora mesmo 


pouco travado — talvez por questoes burocraticas, talvez travados por conta de 
algum analise. 

Encontre um que voce poderia fazer nas horas livres do seu trabalho normal, 
quando voce estaria provavelmente navegando pela internet, checando e-mails 
ou tendo um almo^o por mais de uma hora. Transforme um projeto de meses 
em uma tarefa de menos de uma semana. 
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Capitulo 20 

Leitor de mentes 


Eu trabalhava com um rapaz chamado Rao. Ele vinha de um estado do sul da India 
chamado Andhra Pradesh, mas estava alocado nos Estados Unidos e trabalhava com 
a gente. Ele era o tipo de pessoa que podia codificar qualquer coisa que voce pedisse. 
Se voce precisasse de programa^ao de sistema de baixo nivel, ele era a pessoa a quern 
pedir. Se voce precisasse de programa^ao de aplica^oes de alto nivel, ele poderia 
fazer praticamente tudo que voce pedisse. 

Entretanto, o que tornou Rao verdadeiramente diferenciado foi o que ele fez an¬ 
tes de voce pedir. Ele tinha essa misteriosa habilidade de prever o que voce estava 
prestes a pedir, e o fazia mesmo antes de voce pensar nisso. Era como magica. Acre- 
dito que eu ate o acusei de aplicar truques em mim, em certo ponto, mas nao ha como 
ter sido truque. Eu diria “Rao, estive pensando sobre mudar a forma como estamos 
encapsulando o controlador no framework da nossa aplica^ao. Se nos mudassemos 
apenas um pouco, ele poderia ser usada alem da web. O que voce acha?” 

“Eu fiz isso no comedo dessa semana”, ele diria. “Da uma olhada la no controle 
de versao.” Isso constantemente acontecia com Rao. Era tao frequente que a unica 
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forma de isso ter sido uma coincidencia era se Rao estivesse literalmente fazendo 
qualquer coisa imaginavel com o software que a equipe mantinha. 

Naquela epoca, eu liderava a equipe de arquitetura de aplica^oes da minha em- 
presa. Entre outras coisas, nos construiamos e mantinhamos frameworks para uso 
nas aplica^oes da empresa. Meus colegas de equipe passavam muito tempo conver- 
sando sobre como queriamos ver a area de desenvolvimento de software na empresa 
melhorar. Tambem conversavamos bastante sobre o papel dos componentes de nossa 
infraestrutura basica nessas melhorias. 

E ai que os truques de magica de Rao entravam. Ele nao falava muito nessas 
conversas, mas ele nao era nem um pouco desengajado. Ele ouvia com aten^ao. E, 
entregando seu segredo como nenhum magico faria, ele depois me contou que o 
truque era que ele estava apenas fazendo coisas que eu ja havia dito que queria. Eu 
ja o havia dito de maneira tao sutil que nem eu percebia o que dissera. 

A gente podia estar esperando o cafe ficar pronto e eu dizia sobre como seria 
otimo ter alguma nova flexibilidade no nosso codigo. Se eu o dissesse com frequen- 
cia ou convic^ao suficientes, mesmo sem coloca-lo na lista de afazeres da equipe, Rao 
iria preencher as lacunas entre “trabalho real” analisando a viabilidade de implemen- 
tar um daquelas coisas. Se fosse facil (e barato) de implementar, ele iria eliminar a 
tarefa colocando-a em funcionamento. 

O truque da leitura de mente, sefeito certo,faz as pessoas dependerem de voce. 


Leitura de mente nao apenas se aplica aos seus chefes, mas tambem aos seus 
clientes. Se eles estao dando as dicas certas, voce pode ser capaz de acrescentar fun- 
cionalidades que eles ou vao pedir ou teriam pedido se tivessem percebido que elas 
eram possiveis. Se voce sempre faz o que seus clientes pedem quando eles pedem, 
voce os satisfara. Todavia, se voce fizer mais do que eles pedem, ou se voce ja tiver 
feito antes de eles pedirem, isso ira encanta-los, isto e, ao menos que sua habilidade 
de ler mentes seja defeituosa. 

Esse truque de leitura de mente nao e inteiramente seguro. E uma corda bamba 
sobre a qual voce quer evitar andar, ao menos que haja uma rede segura embaixo. 
Os maiores riscos (alguns atenuados) sao os seguintes: 

• Voce gasta o dinheiro da empresa fazendo trabalho que nao foi pedido. E se 
voce estiver errado? Comece pequeno. So fa^a suposi<;6es do que pode ser 
encaixado nas frestas do seu trabalho normal, de modo que o impacto seja 
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Capitulo 20. Leitor de mentes 


pequeno ou nulo. Se voce esta tao disposto, dedique-se a esse trabalho extra 
no seu tempo livre. 

• Toda vez que voce adiciona codigo em um sistema, voce corre o grande risco 
de torna-lo menos resistente a mudan^as. Evite trabalho de leitura de mente 
que pode for^ar o sistema a um determinado caminho arquitetonico ou limi- 
tar de alguma forma o que ele pode fazer. Quando o impacto da mudan^a 
e grande o suficiente, e necessaria uma decisao de negocio. Raramente sao 
apenas os desenvolvedores que precisam opinar em tal decisao. 

• Voce pode decidir mudar uma funcionalidade que seus clientes pediram, de 
uma maneira que, inesperadamente, a torne menos funcional ou desejavel 
para o cliente. Esteja atento ao adivinhar quando se trata especificamente de 
interface de usuario. 

Gerenciar pessoas e projetos e um trabalho desafiador. Pessoas que podem man- 
ter um projeto andando na dire^ao certa, sem que seja dada muita orienta^ao, pos- 
suem alto valor e sao reconhecidas por seus sobrecarregados gerentes e clientes. O 
truque de leitura de mente, se feito certo, faz as pessoas dependerem de voce - uma 
excelente receita para uma carreira cuja dire^ao voce pode controlar. E uma habili- 
dade que vale ser explorada e desenvolvida. 

Fa$a algo 

1) Um revisor do inicio deste livro, Karl Brophey, sugere que, em seu novo projeto 
ou para um sistema que voce mantem, voce comece a tomar notas sobre o que 
voce acha que os usuarios e chefes vao pedir. Seja criativo. Tente ver o sistema a 
partir do ponto de vista deles. Depois de ter uma lista das funcionalidades nao 
tao obvias que podem aparecer, pense sobre como voce poderia implementa-las 
de forma mais eficiente. Pense sobre casos limites que seus clientes podem nao 
ter em mente imediatamente. 

Conforme voce explora as solicita^oes de melhoria, acompanhe sua taxa de 
acerto. Quantas de suas suposi^oes tornaram-se funcionalidades que realmente 
foram requisitadas? Quando suas suposi^oes vieram a tona, voce foi capaz de 
usar as ideias que vieram em sua sessao de brainstorm ? 
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Capitulo 21 

Exito diario 


Todos nos gostamos de pensar, pela virtude de nosso conhecimento e por sermos 
bons em software, que naturalmente vamos dominar um assunto e virar referenda. 
Para a minoria sortuda (e eu realmente pretendo usar a palavra sorte aqui), uma 
estrategia como essa vai funcionar. 

Porem, todos nos podemos tirar beneficios a partir do agendamento e do acom- 
panhamento do nosso desempenho. O senso comum afirma que se excedermos as 
expectativas dos nossos chefes estaremos na lista A. Dado que exceder as expecta- 
tivas e uma meta digna, surpreendentemente poucos de nos tern mecanismos para 
acompanhar como e quando excederam as expectativas de seus patroes. 

Assim como a maioria das tarefas dignas de serem feitas, tornar-se alguem des- 
tacado e mais provavel com algum trabalho especifico e intencional. Quando foi a 
ultima vez que voce foi alem do chamado de dever? Seu chefe soube disso? Como 
voce pode melhorar a visibilidade desse comportamento? 

Tenha uma realiza^ao para relatar todo dia. 
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James McMurry, um colega de trabalho que tambem e um grande amigo 
(http://semanticnoise.com) , contou-me no inicio de nossas carreiras sobre um sis- 
tema que ele inventou para se certificar de que estava fazendo um bom trabalho. 
Impressionou-me sendo extremamente perspicaz, dada sua experiencia (talvez seja 
uma dica dada por seus pais), e eu o uso ate hoje. Sem avisar seu chefe, ele come- 
90 U a acompanhar seus exitos diarios. Seu objetivo era, cada dia, ter algum tipo de 
conquista marcante para relatar a seu chefe - alguma ideia em que ele pensou ou 
implementou, que tornaria seu departamento melhor. 

Simplesmente estabelecendo um objetivo (diario, semanal, ou quando voce for 
capaz) e acompanhando seus exitos e possivel mudar seu comportamento radical- 
mente. Quando voce come^a a procurar por conquistas marcantes, voce natural- 
mente entra no processo de avaliar e priorizar suas proprias atividades, baseado no 
valor de negocio daquilo em que voce pretende trabalhar. 


\* r cp, ^ 






Figura 21.1: Uma semana de exitos 


Acompanhar seus exitos com uma frequencia razoavelmente alta vai assegurar 
que voce nao fique travado: se voce deve alcan^ar um exito por dia, nao pode passar 
duas semanas elaborando a tarefa perfeita. O tipo de pensamento e trabalho torna- 
se um habito, em vez de uma produijao maior. E, assim como um desenvolvedor 
viciado na barra verde de uma suite de teste de unidade, voce come^a a hear irritado 
se nao alcamjou o exito do dia. Nao e preciso se preocupar muito em acompanhar 
seu progresso, porque agir nesse nivel parece mais com um tique nervoso do que um 
conjunto de tarefas que precisam ser planejadas em um Microsoft Project. 
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Fa$a algo 

1) Separe meia hora de sua agenda, e sente-se com um papel e lapis em um lugar 
tranquilo onde voce nao sera interrompido. Pense sobre as pequenas picuinhas 
dos problemas diarios de sua equipe. Escreva-os. Quais sao as tarefas irritantes 
que gastam alguns minutos do tempo da equipe todo dia, mas que ninguem tern 
tempo ou energia de resolver? 

Em que lugar do seu atual projeto voce esta fazendo algo manualmente que podia 
ser automatizado? Escreva-o. E quanto a seu processo de build ou deploy ? Ha 
alguma coisa que voce poderia limpar? Como voce poderia reduzir falhas em 
seu build? Escreva todas essas ideias. 

De a si mesmo solidos vinte minutos para isso. Escreva todas suas ideias - boas 
ou ruins. Nao se permita terminar antes dos vinte minutos. Depois de ter feito 
uma lista, em um novo papel, escreva seus cinco itens favoritos (mais irritantes). 
Na semana seguinte, na segunda-feira, pegue o primeiro item da lista, e fa^a algo 
a respeito dele. Na ter^a-feira, pegue o segundo item. Na quarta-feira, o terceiro, 
e assim por diante. 
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CAPITULO 22 

Lembre-se de para quem voce 
trabalha 

E muito facil dizer “Certifique-se de que seus objetivos e seu trabalho estejam ali- 
nhados com os objetivos de sua empresa”. E muito facil dizer; mas e muito dificil 
fazer, especialmente quando voce e um programador enterrado sob tantas cama- 
das organizacionais. No initio da minha carreira, eu trabalhava para uma grande 
empresa de entrega de pacotes, em uma equipe de arquitetura de desenvolvimento 
de software apoiando os sistemas definidos pela empresa. Ela estava tao entravada 
com hierarquia, que eu nunca vi nada no meu trabalho diario que chegasse perto de 
entrega de pacotes. Lembro-me de minha equipe participando das reunioes trimes- 
trais, sentindo-se completamente deslocados e alienados. “Qual e a conquista que 
estamos comemorando? O que toda essa metrica significa?” 

De fato, nesse ponto de minha carreira, eu estava mais interessado em construir 
sistemas elegantes e hackear softwares open sources, do que mergulhar nas profun- 
dezas de um negocio de entrega de pacotes. (OK, eu admito - eu ainda sou mais 
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interessado naquelas coisas). Mas se eu realmente quisesse alinhar meus objetivos 
com os da empresa, eu nao tenho certeza se eu saberia por onde come^ar. 

Entao esta certo dizer que precisamos alinhar nosso trabalho com as metas da 
empresa - para tentarmos assegurar que estamos impactando o ponto de partida 
de tudo aquilo. Contudo, que a verdade seja dita, muitos de nos simplesmente nao 
enxerga como fazer isso do lugar onde estao. Nao podemos ver a floresta por causa 
das arvores. 

Talvez isso nao seja nossa culpa. Talvez estejamos cobrando muito de nos mes- 
mos. Talvez a ideia de tentar impactar diretamente a empresa seja equivalente a ten- 
tar ferver o oceano. Portanto, precisamos ter uma visao mais compartimentada, di- 
vidindo o negocio em po<;as ferviveis. 

A pocja mais obvia com a qual come^ar e sua propria equipe. E provavelmente pe- 
quena e suficientemente focada, de modo que voce pode conceitualmente se envol- 
ver em torno dela. Voce muito provavelmente entende os problemas que sua equipe 
enfrenta. Voce sabe no que ela esta focada em melhorar, seja na produtividade, no 
rendimento, reduijao de erro, ou qualquer outra coisa. Se voce nao tern certeza, ha 
um lugar obvio para se descobrir: seu chefe. 

Em ultima analise, em um ambiente bem estruturado, os objetivos de seu chefe 
sao os mesmos de sua equipe. Resolva o problema de seu chefe e tera resolvido um 
problema para a equipe. Adicionalmente, se seu chefe possui a mesma abordagem 
que voce, os problemas que voce esta resolvendo para ele, na verdade, sao os pro¬ 
blemas do chefe dele. E assim por diante, ate que isso chega no nivel mais alto da 
empresa - o CEO, os acionistas, ou ate mesmo os consumidores. 

Fazendo sua pequena parte, voce estara contribuindo para a realizaijao das metas 
de sua empresa. Isso pode dar-lhe um senso de proposito. Isso da significado ao seu 
trabalho. 

Alguns podem resistir a essa estrategia. “Eu nao vou fazer esse service para ele”, 
ou, “Ela vai levar credito pelo meu trabalho!” 

Bom, sim. Mais ou menos. E assim que funciona. O papel de um bom chefe 
nao e, como Lister e DeMarco dizem em Peopleware [2], “ser um jogador reserva do 
time”, sabendo fazer todo o trabalho da equipe. O papel de um bom chefe e colocar 
prioridades para a equipe, certificar-se de que ela tern o que precisa para realizar o 
trabalho, e fazer o que for preciso para manter a equipe motivada e produtiva, por 
fim, fazer o que deve ser feito. Um trabalho bem feito pela equipe e um trabalho bem 
feito pelo chefe. 

O sucesso de seu chefe e 0 seu sucesso. 
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Se a fun^ao do chefe e saber e estabelecer prioridades, mas nao pessoalmente 
realizar o trabalho, logo, sua fun^ao e fazer todo o trabalho. Voce nao esta fazendo 
o service de seu gerente. Voce esta fazendo seu service. 

Se voce realmente esta preocupado com quem recebe os creditos, lembre-se que 
e seu chefe que detem as chaves de sua carreira (em sua atual empresa, pelo menos). 
Na maior parte das empresas, e o chefe direto quem influencia a avalia^ao das per¬ 
formances, a^oes salariais, bonus e promotes. Portanto, o credito que voce busca 
fica depositado com seu gerente. 

Lembre-se de para quem voce trabalha. Voce nao vai somente se alinhar com as 
necessidades do negocio, mas alinhar o negocio com suas necessidades. Se voce vai 
dominar a execu^ao de sua fun^ao, isso vai assegura-lo de executar as coisas certas. 

Fa$a algo 

1) Agende uma reuniao com seu chefe. Esse compromisso e para voce entender as 
metas de seu chefe para a equipe para o proximo mes, trimestre, e ano. Pergunte 
como voce pode fazer a diferen^a. Apos a reuniao, examine como seu trabalho 
diario se alinha aos objetivos de sua equipe. Fa^a com que eles sejam um filtro de 
tudo o que voce faz. Priorize seu trabalho de acordo com esses objetivos. 
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Capitulo 23 

Esteja onde voce esta 


Como chefe, posso dizer que a coisa mais frustrante e lidar com um funcionario que 
esta sempre almejando o proximo degrau da escada. Voce conhece o tipo: voce nao 
consegue sentar com ele no almoijo sem que ele traga o assunto de quern recebeu 
qual promo^ao. Ele sempre tern algum tipo de fofoca do escritorio para espalhar, e 
ele parece se apegar a politica corporativa como se fosse o enredo de uma novela na 
qual ele seja viciado. Ele reclama sobre a incompetencia da gerencia, e com muito 
desgosto completa suas tarefas, sabendo muito bem que ele podia exercer a fun^ao 
de chefe melhor do que eles. Eles so sao incompetentes para entender seu potencial. 

Ele pensa que muitas tarefas estao abaixo dele. Ele as evita quando possivel e 
as faz a contragosto (e lentamente), quando nao. Ele escolhe trabalhos que acha, 
mesmo subconscientemente, que estao de acordo com seu nivel e que podem leva- 
lo a proxima promo^ao. 


Seja ambicioso, mas nao demonstre. 
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A coisa triste sobre esse cara e que, pelo fato de ele estar vivendo em seu proximo 
emprego, ele geralmente esta fazendo um trabalho mediocre na sua fun^ao atual. E 
como aparar a grama para mim. Eu detesto aparar a grama. Isso me da coceiras e 
me faz suar. Pior de tudo, isso faz com que eu nao fa<;a algo que eu preferia estar 
fazendo. Voce pode contratar pessoas para apararem sua grama. Eu fui uma dessas 
pessoas. Isso foi ha muito tempo, e agora eu progredi. Entao, quando eu preciso 
aparar a grama, o que eu fai;o? Eu me apresso. Fa^o um servi^o desleixado. Passo o 
tempo todo pensando em como acabar logo com isso para que eu possa me dedicar 
as coisas que eu preferia fazer. Resumindo, eu iaqo um pessimo service ao aparar a 
grama. 

Ainda bem que, no meu exemplo de aparar a grama, ninguem esta me obser- 
vando e me avaliando (apesar de que minha esposa ficou tao irritada que eu nao sou 
mais o responsavel pela grama na nossa casa). O problema e meu se a grama nao 
esta otima quando conclui o trabalho. Ninguem esta me segurando para ser “apenas 
um cortador de grama” por causa da minha performance no jardim. No caso de um 
emprego de TI, o mesmo comportamento pode provocar uma catastrofe em uma 
carreira. Voltando ao nosso amigo dos paragrafos anteriores, como voce acha que 
a administra^ao o vera? Eles verao que estavam errados ao negligenciar seu talento 
brilhante e decidirao promove-lo? Eles darao grandes aumentos para faze-lo feliz? 

Claro que nao. Ele e um funcionario ridiculo com uma atitude ruim. E dal se 
ele tern alto potencial! Por enquanto, ele nao o esta mostrando. A empresa nao faz 
dinheiro por causa de potencial. Acionistas nao mantem seus investimentos se o 
potencial nao e efetivado. Alem disso, sua atitude faz seus chefes quererem parar de 
investir nele. 

Entao, esse e o ponto de vista de um gerente. Agora, claro, eu nao estou com- 
pletamente isento de culpa aqui. Eu fui essa pessoa por algum tempo. Tambem nao 
e muito bom desse lado da rua. Voce passa todo seu tempo desejando algo. Desejo 
e o oposto de satisfa^ao. Voce acorda de manha e tern que ir para “aquela droga de 
emprego” onde ninguem entende seu potencial. Com ressentimento, voce labuta em 
seu service, repassando estrategias para subir de cargo. Voce fantasia sobre o que 
voce faria na ultima situa^ao em que seu chefe errou as coisas - como voce lidaria 
com isso diferentemente. Voce adia viver enquanto voce esta trabalhando ate que 
voce possa fazer do seu jeito, na posi^ao que voce merece. 

Aqui esta um segredo: essa sensa^ao nunca vai passar. Se e quando voce final- 
mente conseguir a grande promo^ao com a qual voce tern sonhado, voce rapida- 
mente vai se cansar e perceber que nao e este trabalho que voce queria - e o pro- 
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Capitulo 23. Esteja onde voce esta 


ximo. O ciclo come^a de novo. Eu ainda nao alcancei o topo, mas eu tenho a forte 
intui^ao de que se houvesse tal posi^ao, e eu a alcamjasse, eu olharia para cima e 
perceberia que estava perseguindo um fantasma. Que frustrante desperdi'cio de vida 
profissional. 

Mas nos nao deveriamos ter ambi^oes? Haveria uma Microsoft ou uma General 
Electric se grandes empreendedores nao tivessem ambicionado e tido metas? 

Claro que deveriamos. Eu nao estou defendendo uma visao apatica. E bom ter 
objetivos, e e bom querer ter sucesso. Mas pense no cara negativo e ressentido que 
eu descrevi no comedo desse capitulo. Voce acha que ele vai ser a pessoa que tern su¬ 
cesso? Parece retrogrado, mas focar-se no presente vai leva-lo mais longe em dire^ao 
aos seus objetivos, do que manter sua mente focada no objetivo em si. 

Voce vai descobrir que isso e muito pragmatico. Focar no presente vai permitir- 
lhe aproveitar as pequenas vitorias do dia a dia de trabalho: a sensa^ao de trabalho 
bem feito, a sensa^ao de ser considerado um expert em um problema critico de ne- 
gocio, a sensa^ao de ser um membro integral de uma equipe bem sucedida. 

Isso e o que voce vai perder se estiver sempre com a cabe^a nas nuvens. Voce es- 
tara sempre esperando o grandioso, enquanto ignora as pequenas coisas que acon- 
tecem todo dia, que fazem valer a pena aparecer em seu serviijo. 

Nao apenas voce vai se sentir bem, mas aqueles ao seu redor tambem vao. Seus 
colegas de trabalho, chefes e clientes vao senti-lo. Isso vai transparecer no seu tra¬ 
balho. Por mais contraintuitivo que pare^a, deixar de lado seu desejo de ter sucesso 
resultara em uma aprimorada habilidade de ser bem sucedido. 

Voce e proximo aos seus clientes. Voce e proximo aos lideres com poder de de- 
cisao que vao modelar sua carreira a curto prazo e, possivelmente, a longo prazo. 
Desenvolvedores na India ou nas Filipinas nao possuem essa vantagem, mas voce 
tern. Portanto, esteja onde voce esta. 

Fa$a algo 

1) Coloque as metas de sua carreira de lado por uma semana. Escreva seus obje¬ 
tivos para seu emprego atual. Em vez de pensar sobre aonde voce quer ir em 
seguida, pense sobre o que voce quer ter alcan^ado quando voce terminar o tra¬ 
balho no qual esta agora. O que voce pode ter produzido nesse emprego que tera 
sido otimo? Crie um piano que seja ambos estrategico e tatico. Passe a semana 
implementando essas taticas em apoio as metas a longo prazo de “terminar” esse 
trabalho. 
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Durante aim 090s e intervalos com seus colegas, foque a conversa nesses objetivos. 
Quanto tempo vai passar ate que voce conquiste tudo o que sente que precisa 
em sua fun^ao atual? Como voce sabera que tera concluido? Planeje a proxima 
semana e repita. 
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Capitulo 24 

Quao bom eu posso fazer um 
trabalho hoje? 

E recompensador realizar um bom trabalho e ser reconhecido. Embora a maioria de 
nos saiba disso intuitivamente, somos extremamente seletivos sobre onde e quando 
realmente vamos alem do nosso trabalho para nos sobressairmos. Nos podemos 
nos dedicar cegamente ao design do Novo Grande Projeto do departamento de mar¬ 
keting, ou nos rapidamente mergulhamos em um problema para salvar o dia em 
alguma grande catastrofe, porque nossos cerebros estao programados para entender 
tais momentos como oportunidades de exibir nosso notorio material. Podemos ate 
mesmo fazer o trabalho no meio da noite, com um nivel de foco de detalhe que nor- 
malmente nos levaria as lagrimas. Uma situa^ao terrivel pode frequentemente fazer 
surgir o melhor em nos. 

Eu ja deixei essa sensa^ao inebriante de exalta^ao manter-me acordado e efeti- 
vamente trabalhando em algumas das mais cansativas falhas de sistema e prazos nao 
cumpridos. Por que e que, quando nao ha grandes pressoes, nos geralmente nao so- 
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mos capazes desse tipo de comportamento de altruismo e de frenesi ultraprodutivo? 
Quao bem nos atuariamos se pudessemos tratar as tarefas mais desinteressantes e 
chatas com o mesmo desejo fervoroso de faze-las direito? 

Quao mais divertido vocepode tornar seu trabalho? 


A ultima questao fica melhor se a reescrevermos. Quao mais divertido seria seu 
trabalho se voce pudesse tratar as tarefas mais chatas com o mesmo desejo fervo¬ 
roso de faze-las direito? Quando temos mais diversao, fazemos um melhor trabalho. 
Entao, quando nao temos interesse em uma tarefa, ficamos entediados e, como re- 
sultado, nosso trabalho tambem sofre. 

Como transformar um trabalho entediante em um mais divertido? A resposta a 
essa pergunta pode ser mais aparente se voce inverte-la. Por que o trabalho entedi¬ 
ante e entediante? Por que ele ainda nao e divertido? Qual a diferen^a entre trabalho 
que voce aprecia e trabalho que voce abomina? 

Para muitos de nos, tecnicos, o trabalho entediante e assim por dois motivos 
primarios. O trabalho que amamos nos permite flexionar nossos musculos criativos. 
Desenvolvimento de software e um ato criativo, e muitos de nos somos atraidos para 
isso por essa razao. O trabalho que nao amamos e raramente o que consideramos 
de natureza criativa. Pense sobre isso por um momento. Pense sobre o que esta 
em sua lista de tarefas para a proxima semana. As tarefas que voce adoraria pular 
provavelmente nao dao muito espa^o para a imagina^ao. Elas sao apenas tarefas a 
fazer, que voce gostaria de poder delegar a outra pessoa. 

A segunda razao pela qual tarefas chatas sao chatas, e relacionada a primeira, 
e que as tarefas chatas nao sao desafiadoras. Nos amamos mergulhar em um pro- 
blema dificil e resolver coisas que outros nao conseguiram. E o mesmo sentimento 
que motiva membros de nossa especie a recreativamente arriscar suas vidas esca- 
lando montanhas e saltando de bungee jump. Amamos fazer coisas para provar que 
somos capazes. Tarefas chatas normalmente nao estimulam o cerebro. Faze-las e tao 
desafiador quanto colocar o lixo para fora de casa. 

Entao como e possivel ainda usarmos nossa criatividade e desafiar a nos mes- 
mos enquanto tendemos as sobras mundanas do nosso dia de trabalho (que prova¬ 
velmente tomam mais de 80% do tempo da maioria de nos)? 

E se voce tentasse fazer as coisas chatas perfeitamente? Digamos que, por exem- 
plo, voce odeia teste de unidade. Voce ama programar, mas fica entediado em ter de 
escrever codigo de teste automatizado. E se voce se esforcjar para fazer seus testes 
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Capitulo 24. Quao bom eu posso fazer um trabalho hoje? 


perfeitos? Como isso mudaria seu comportamento? O que perfeito significa em re- 
la^ao a teste de unidade? Provavelmente tera algo a ver com cobertura de teste. Isso 
significaria que voce testou 100% da funcionalidade do seu codigo. Testes de unidade 
perfeitos tambem sao limpos e de facil manuten^ao, e nao dependem de muitos fa- 
tores externos que podem ser dificeis de replicar em outro computador. Eles deviam 
ser executaveis diretamente depois de um checkout no controle de versao. E, e claro, 
todos os testes deviam passar. 

Isso esta come^ando a parecer dificil; uma cobertura de teste de 100% e quase 
imposslvel. E o negocio de dissocia^ao de testes de modo que eles possam rodar sem 
dependences externas apresenta varios desafios. Alias, voce provavelmente tera que 
modificar seu codigo para tornar isso possivel. Mas, se voce pudesse faze-lo, os testes 
seriam incriveis. 

Eu nao sei quanto a voce, mas isso me parece ate divertido. De fato, voce pode 
aplicar o mesmo pensamento para a maioria das tarefas que cruzam seu caminho. 
Tente isso amanha. 

Olhe para seu trabalho e pergunte a si mesmo: “Quao bom eu posso fazer isso 
hoje?” Voce descobrira que voce gostara mais de seu emprego e ele gostara de voce. 

Fa$a algo 

1) Torne isso visivel — Transforme aquelas tarefas chatas em uma competi^ao com 
seus colegas de trabalho. Veja quern pode faze-las melhor. Nao gosta de escrever 
testes de unidade? Imprima o numero de asserts dos seus testes todo dia, e o 
pendure em sua parede. Mantenha uma tabela de pontos para a equipe inteira. 
Compita pelo direito de se gabar (ou mesmo por premios). Ao final, fa^a com que 
o vencedor ganhe um premio, por exemplo, ter os testes feitos por outra pessoa 
da equipe por uma semana. 
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Capitulo 25 

Quanto voce vale? 


Voce ja parou para analisar exatamente quanto voce custa para a empresa na qual 
trabalha? Quero dizer, voce sabe o seu salario. Esta parte e facil. Mas e quanto a 
beneficios, despesas de gerenciamento, e todas as outras coisas que nao necessaria- 
mente aparecem em seu holerite? 

E facil simplesmente querer mais. Infelizmente, isso parece ser uma tendencia 
basica humana, de fato. Voce recebe um aumento e isso faz-lhe sentir bem por um 
tempo, mas a partir de entao voce come^a a pensar no proximo. “Se eu pudesse fazer 
apenas 10% mais, eu poderia comprar aquele novo...” Todos nos fizemos isso. Em 
algum momento, o numero verdadeiro se torna abstrato. Nao se trata mais de 10% a 
mais por mes. Trata-se de fazer qualquer que seja o numero atual subir mais. Se nao 
recebemos um aumento de salario satisfatorio em um ano, tornamo-nos insatisfeitos 
com nosso trabalho e nossa empresa. “Por que eles nao gostam de mim?” 

Quanto voce realmente custa? Como eu ja mencionei, e obviamente mais do que 
seu salario basico. Por uma questao de discussao, vamos fazer a estimativa com duas 
vezes seu salario. Entao, se voce ganha 5 mil por mes, a empresa realmente gasta em 
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torno de 10 mil mantendo voce empregado. 

Isso foi facil. Agora a parte dificil: quanto valor voce produziu no ano passado? 
Qual foi seu impacto positivo no resultado final da empresa? Ja sabemos que voce 
custa a empresa (em nosso cenario imaginario) aproximadamente 10 mil por mes. 
O que voce deu em troca? Quanto dinheiro voce fez a empresa economizar? Quanto 
mais contribuiu na receita dela? 

Esse numero e maior do que o dobro do seu salario? 

E um exercicio complicado de fazer, porque geralmente e dificil relatar cada as- 
pecto de seu trabalho no resultado final da empresa. Pode ate parecer uma pergunta 
sem sentido para voce. “Como eu vou saber? Eu sou apenas um programador!” 
Este, e claro, e o ponto. Voce trabalha para um negocio e, ao menos que voce for- 
ne^a algum tipo de valor real, voce e um desperdicio de dinheiro. E facil cair na 
armadilha de pensar que aumentos de salario sao um direito. Analogamente, uma 
empresa tern o direito de cobrar mais por seus produtos todo ano. Mas, por sua vez, 
os consumidores tern o direito de nao comprar aquele produto se o pre^o nao os 
atrair. 

Agora que voce comeqiu a pensar sobre quanto voce custa versus quanto voce 
entrega, quanto voce acha que voce precisa entregar para ser considerado um inves- 
timento de valor a empresa? Conversamos sobre o cenario do dobro de seu salario, 
mas isso e o suficiente? Se voce entregar valor totalizando o dobro de seu salario, a 
empresa ficou no zero a zero. Este e um bom jeito de gastar dinheiro? 

Como um ponto de referenda, pense sobre a taxa de juros de uma conta pou- 
pan^a de um cliente comum. Nao e la grande coisa, certo? Ainda assim, e definiti- 
vamente melhor que zero. Dadas as opijoes, voce colocaria as economias de um ano 
em uma conta poupan^a que produz o% ou 3%? Entregar apenas o seu salario como 
valor nao e interessante do ponto de vista de uma empresa, assim como uma conta 
poupan^a de 0% e para voce. Eles se comprometeram a 10 mil por mes, e voce nao 
esta nem mesmo entregando valor suficiente para acompanhar a taxa de infla^ao da 
economia. Um empate neste caso e, na verdade, ainda uma perda. 

Lembro de quando comecei a pensar dessa maneira. Isso me deixou paranoico 
no comedo. Um mes se passava, e eu ficava pensando: “O que eu entreguei este mes?” 
Entao, eu comecei a hear tao granular como as semanas e dias. “Fui valioso hoje?” 

Pergunte-se: “Fui valioso hoje?” 


Voce pode tornar isso concreto. Apenas quanto valor voce adiciona? Converse 


108 



Casa do Codigo 
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com seu chefe sobre a melhor forma de quantifica-lo. O puro fato de voce querer 
quantifica-lo sera levado como uma coisa boa. Como voce poderia criativamente 
economizar o dinheiro da empresa? Como voce poderia tornar sua equipe de de- 
senvolvimento mais eficiente? Ou e quanto aos usuarios finais de seu software? Voce 
se surpreendera com quantas oportunidades voce pode identificar se come^ar a fazer 
essas perguntas. Agora, comece a implementar algumas delas. Mantenha essa ima- 
gem em sua cabe^a: o dobro do meu salario. Nao pare ate que voce tenha superado 
aquele numero para o ano. 

Fa$a algo 

1) Quando empresas fazem investimentos, eles tentam se assegurar que estao 
usando seu dinheiro da melhor maneira possivel. Simplesmente calcular o re- 
torno de um investimento (eu coloco 100 e obtenho 120) nao e o suficiente para 
tomar uma decisao inteligente. Dentre outros fatores, empresas tern que conside- 
rar infla^ao, custo de oportunidade e riscos. Especificamente nao-intuitivo para 
aqueles que nao frequentaram faculdade de economia ou administra^ao, esta o 
conceito de valor do dinheiro no tempo. Com o risco de estar simplificando de- 
mais, e algo assim: um dolar hoje vale mais que um dolar no ano que vem, porque 
um dolar hoje pode ser usado para gerar mais dolares. 

A maioria das empresas estabelece uma barra da taxa de retorno, abaixo da qual 
um investimento nao sera feito. Investimentos devem render uma porcentagem 
acordada em um periodo de tempo acordado, ou eles nao sao feitos. Este numero 
e chamado de taxa minima. 

Descubra qual a taxa minima de sua empresa, e aplique isso a seu salario. Voce e 
um bom investimento? 
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Capitulo 26 

Uma pedrinha em um balde d agua 


O que aconteceria se voce se levantasse e saisse de seu escritorio para nunca mais 
voltar? Conheijo varios programadores que sentem um certo prazer ao imaginar essa 
cena. Voce apenas se levanta, dirige-se a sala de seu chefe, e comunica sua demissao. 
Vou mostrar para eles por que eles precisam de mim! E quase um sonho para 
ajuda-lo a atravessar os dias realmente ruins, mas obviamente nao e uma atitude 
muito inteligente para se ter com voce o tempo todo. 

Alem disso, nao e verdade. Pessoas deixam empresas todos os dias. Muitas de- 
las sao despedidas. Muitas escolhem se demitir. Algumas ainda tentam viver suas 
ilusoes e saem sem aviso previo. Mas em alguns casos, as empresas que eles deixam, 
na verdade, sentem um impacto significante depois de suas saidas. Na maioria dos 
casos, mesmo em posi^oes criticas, o efeito e surpreendentemente baixo. Sua pre¬ 
sent^ no trabalho e, para a empresa, como uma pedrinha em um balde d agua. E 
claro que o nivel da agua e mais alto como resultado. Voce faz as coisas. Voce faz sua 
parte. Mas, se voce tirar a pedrinha do balde e se afastar para olhar a agua, voce nao 
consegue realmente ver a diferen^a. 
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Nao estou tentando deixar voce deprimido. Todos nos precisamos sentir que 
nossas contributes significant alguma coisa. E elas significant. Mas passamos tanto 
tempo sendo um eu, que podemos facilmente esquecer que todos os outros sao um 
eu tambem. Todos os funcionarios de sua empresa andam por ai, um ser sensivel e 
autonimo, presos a esta coisa chamada ego, que e a unica janela pela qual eles veem 
seus empregos. Pense assim: se voce se demitisse amanha, a diferen^a seria (em 
media) nao mais nem menos impactante que se algum de seus colegas saisse. 

Uma vez trabalhei para um CIO que era um dos mais poderosos em uma das 
maiores empresas do mundo. Ele e sua equipe (da qual eu fazia parte) recebiam todos 
os premios e estabeleciam todos os padroes de TI da empresa. Esse era um cara que, 
obviamente, tinha descoberto algum tipo de elixir magico e o estava distribuindo em 
almo^os e jantares que ele oferecia. 

Um dos poucos conselhos que eu ja recebi deste CIO — e eu o ouvi varias vezes 
— e que voce nunca deveria ficar muito confortavel. Ele declarou que, todo dia ao 
acordar, ele intencional e explicitamente lembrava-se que ele podia ser tirado de seu 
pedestal a qualquer dia. Hoje pode ser o dia, ele dizia. 

Seus funcionarios olhavam para ele, incredulos. Nao. Hoje nao pode ser o dia. 
As coisas estao indo tao bem. Tern muita coisa acontecendo para voce. 

Tenha cuidado para nao se cegar com o proprio sucesso. 


Este era o ponto. Humildade nao e apenas algo que desenvolvemos para alegar 
que somos mais espirituais. Ela tambem nos permite ver nossas a (joes mais clara- 
mente. O que nosso CIO estava nos ensinando era que quanto mais bem sucedido 
voce e, e mais provavel que voce cometa um erro fatal. Quando varias coisas es¬ 
tao acontecendo para voce, e menos provavel que voce questione seu proprio jul- 
gamento. Quando a maneira como voce sempre fez sempre funcionou, e menos 
provavel que voce reconhecja que um jeito novo pode funcionar melhor. Voce se 
torna arrogante, e com isso desenvolve pontos cegos. Quanto mais insubstituivel 
voce pensa que e, mais substituivel voce e (e voce se torna menos desejavel). 

Sentir-se insubstituivel e um mau sinal, especialmente sendo um desenvolvedor 
de software. Se voce nao pode ser substituido, isso provavelmente significa que voce 
realiza tarefas de tal modo que os outros nao conseguem fazer. Mesmo que todos 
nos gostariamos de ser considerados algum tipo de genio especial, poucos desenvol- 
vedores de softwares sao tao inigualaveis que, de fato, deveriam ser insubstituiveis. 
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Capitulo 26. Uma pedrinha em um balde dagua 


Ja ouvi varios programadores meio que brincando sobre criar uma “seguran^a 
de emprego” com codigo nao manutenivel. E vi programadores realmente tentarem 
fazer isso, por incrivel que pare^a. Em todos os casos, essas pessoas viraram alvos. 
Claro, era assustador para a empresa finalmente demiti-los. Tentar ser insubstituivel 
e uma estrategia defensiva que cria um relacionamento hostil com seu empregador 
(e com seus colegas) onde antes nao existia. 

Usando essa mesma logica, tentar ser substituivel devia criar um relacionamento 
de trabalho nao hostil. Todos nos somos substituiveis. Aqueles de nos que abra^am 
essa ideia e mesmo trabalham em dire^ao a isso, na verdade, diferenciam-se e, nao 
intuitivamente melhoram suas proprias chances. 

Fa$a algo 

1) Fa<;a um inventario do codigo que voce escreveu ou que voce mantem e todas as 
tarefas que voce realiza. Anote qualquer coisa em que a equipe e completamente 
dependente de voce. Talvez voce seja o unico que entende totalmente do pro- 
cesso de desenvolvimento de sua aplica^ao. Ou ha uma se^ao do codigo que voce 
escreveu que e especialmente dificil para o resto da equipe entender. 

Cada um desses itens vai para sua lista de tarefas. Documentar, automatizar, ou 
refatorar cada peda^o de codigo ou tarefa, de modo que eles possam ser facil- 
mente compreendidos por qualquer um de sua equipe. Fa^a isso ate que voce 
complete a lista original. Compartilhe proativamente esses documentos com sua 
equipe e com seu lider. Certifique-se de que os documentos sejam guardados em 
algum lugar para que permane^am de facil acesso a equipe. Repita esse exercicio 
periodicamente. 
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Capitulo 27 

Aprenda a amar manuten^ao 


Muitos anos atras, eu estava engajado em fazer um centro de desenvolvimento de 
software para 250 pessoas, do zero. Come^amos com um predio vazio e fomos de- 
signados a contratar e montar toda a equipe de desenvolvimento. Nesse processo, 
a gente se deparou com um desafio inesperado. Todos queriam fazer novos siste- 
mas. Ninguem queria manter sistemas antigos. Queriamos criar um novo ambiente 
com uma nova cultura energizada, entao tinhamos de prestar aten^ao ao que nossos 
novos funcionarios queriam, se iriamos come^ar no caminho certo. 

Todo mundo gosta de criar. E quando sentimos que nos e dada a oportunidade 
de realmente deixar nossa marca em um trabalho. Sentir que nos somos seu dono. 
Expressarmo-nos atraves de nossa cria^ao. Nos tambem tendemos a acreditar que os 
projetos novos sao os mais visiveis para nossas empresas. As pessoas que constroem 
a nova gera^ao sao as que devem receber o merito, certo? Eu sabia que essa atitude 
prevalecia entre os programadores com quern eu havia trabalhado anteriormente. 
Mas, lidando com mais de duzentos desenvolvedores, vi isso levado a um extremo 


que eu nunca esperava. 
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Embora desenvolvedores de software sejam tipicamente criativos, pessoas aman- 
tes de liberdade, a “sociedade” de programadores e surpreendentemente como a de 
castas. Programadores querem ser designers, que querem ser arquitetos, e assim por 
diante. Dar manuten^ao nao proporciona nenhuma badge nem um papel maior, 
como um arquiteto, para contar para seus pais e colegas de faculdade. 

Entao, os fatores de motiva^ao sao a habilidade de ser criativo e a chance de dar 
passos em dire^ao a uma promo^ao. O engra^ado e que trabalhar em projetos novos 
nao necessariamente e o melhor lugar para fazer ambos. 

Dar manuten^ao geralmente significa viver em um mundo cheio de sistemas ve- 
lhos e deteriorados, e usuarios finais insistentes. Uma vez que o software e tido como 
feito, os departamentos de TI geralmente se focam em reduzir o custo de manuten- 
9ao desses sistemas, de modo que possam buscar a maneira mais barata possivel para 
mante-los funcionando. 

Isso geralmente se soma a pouquissimos recursos destinados a cuidar dos siste¬ 
mas e a investimentos insignificantes de dinheiro direcionado a rejuvenesce-los. 

Trabalhar em um projeto novo, por outro lado, e onde voce come^a com um 
mundo novo, limpo e verde. Em uma empresa bem administrada, cada projeto con- 
tribui para fazer, ou economizar, dinheiro, assim os projetos sao geralmente financi- 
ados de modo suficiente para serem concluidos (embora experiences possam variar 
aqui). Nao ha um campo minado de codigo antigo obrigando os programadores a 
andarem cuidadosamente nas pontas dos pes para poderem desenvolver funciona- 
lidades corretamente, com menos empecilhos do que se estivessem trabalhando em 
um sistema legado. Em suma, as circunstancias nos projetos novos sao geralmente 
muito mais ideais. 

Se eu lhe der mil reais e pedir que me traga uma xicara de cafe, ficarei muito triste 
se voce voltar com menos mil reais e nenhuma xicara de cafe. Eu ficarei triste ate se 
voce me trouxer um cafe realmente bom, mas demorar duas horas. Se eu nao lhe der 
dinheiro e pedir uma xicara de cafe, ficarei extremamente grato se voce efetivamente 
voltar com um cafe, e serei compreensivo se nao. Trabalhar em um projeto novo e 
como o primeiro cenario. Manuten^ao e como o segundo. 

Quando nao temos as restriijoes do codigo legado ruim e de falta de fundos, 
nossos gerentes e clientes legitimamente podem esperar mais de nos. E, em pro¬ 
jetos novos, ha uma melhoria de negocio esperada. Se nos nao entregarmos, nos 
falhamos. Uma vez que nossas empresas estao contando com essas melhorias, eles 
vao frequentemente apertar as redeas naquilo que for criado, como, e para quando. 
De repente, nosso playground de criatividade come^a a parecer mais uma opera^ao 
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militar — qualquer movimento nosso e ditado de cima. 
Manuten^do pode ser um lugar de liberdade e criatividade. 


Mas no lado da manutemjao, tudo o que e esperam que fa^amos e manter o soft¬ 
ware rodando sem problemas e com o minimo custo possivel. Ninguem espera nada 
chamativo da equipe de manutemjao. Tipicamente, se tudo estiver indo certo, os 
clientes ficarao alheios a seu trabalho. Consertar erros, implementar pequenas soli- 
citaijoes de funcionalidades, e mante-las rodando. Isso e tudo que voce precisa fazer. 

E se um erro aparece e exige que se refa^a uma parte da aplica^ao? Isso e tudo 
parte do conserto de erros, certo? O design deve estar antigo e embolorado, e janelas 
quebradas devem estar espalhadas pelo sistema. 


Teoria das janelas quebradas 

Para conhecer a teoria das janelas quebradas, voce pode ler o livro The 
Pragmatic Programmer [7]. 


Ai esta uma oportunidade de colocar suas refatoraijoes em teste. Quao elegante 
esse sistema pode ser? Quanto mais rapido voce pode consertar ou aprimorar esta 
seijao na proxima vez devido a refatoraijao que voce esta fazendo agora? 

Enquanto voce continuar a mante-lo rodando e respondendo as solicita^oes dos 
usuarios em tempo habil, o modo de manuten^ao e um lugar de liberdade e criati¬ 
vidade. Voce e lider de projeto, arquiteto, designer, programador e testador. Voce 
pode modelar suas habilidades criativas da forma de que gosta, e e voce quern vai 
suportar os sucessos ou as falhas do sistema. 

Quando voce esta fazendo a manuten^ao de um sistema, voce tambem pode 
planejar melhorias mais visiveis. Seu sistema web de 3 anos de idade pode nao levar 
vantagem de algumas das novas interfaces impertinentes de usuario disponiveis para 
os browsers modernos. Se voce pode trabalhar entre manter o sistema rodando e 
consertar os erros, voce poderia visivelmente aprimorar a experiencia do usuario 
com o sistema. Adicionar algumas funcionalidades bem colocadas que seus clientes 
nao estavam esperando nao e tao diferente do que surpreender sua esposa com flores, 
ou, enquanto crian^a, limpar a casa quando seus pais estao fazendo compras. E, sem 
a burocracia de um projeto em pleno desenvolvimento, voce se surpreendera com 
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o quanto voce pode se encaixar nesses pequenas frestas. Seus clientes tambem se 
surpreenderao. 

Uma vantagem oculta de dar manuten^ao e que, diferente do ambiente contra- 
tual de muitos dos projetos atuais, o programador que da manuten^ao geralmente 
tem a oportunidade de interagir diretamente com seus clientes. Isso significa que 
mais pessoas saberao quem voce e, e voce tera a chance de construir uma base mais 
larga de defensores em seu negocio. Isso tambem o coloca em um lugar especial para 
verdadeiramente aprender o funcionamento interno do seu negocio. 

Se voce e responsavel por uma aplica^ao em sua totalidade, sempre trabalhando 
com seus usuarios finais atraves dos problemas e questoes, ha mais chances de que, 
mesmo sem muito esforijo, voce entenda o que a aplica^ao realmente faz tao bem 
quanto muitos de seus usuarios. Regras de negocio sao implementadas em uma 16 - 
gica que mesmo pessoas de negocio nao conseguem entender. Ja vi muitas situates 
em que so os programadores que entendiam como um processo especifico funci- 
onava em uma empresa. Ninguem mais tinha exposi^ao direta ao codigo daquela 
logica. 

A grande ironia em rela^ao a separa^ao de projeto versus manuten^ao e que tra- 
balhar em projeto novo e manuten^ao. Assim que sua equipe de projeto escreveu 
a primeira linha do codigo, cada funcionalidade adicional esta sendo enxertada em 
uma base de codigo vivo. Claro, o codigo deve ser o mais limpo ou deve ser menor 
do que se voce estivesse trabalhando em uma aplica^ao legada, mas o ato basico e o 
mesmo. Novas funcionalidades sao adicionadas e erros sao consertados no codigo 
existente. Quem sabe como fazer isso melhor e mais rapido do que alguem que real¬ 
mente adotou o ato de dar manuten^ao e estabeleceu como missao aprender a fazer 
isso direito? 

Fa$a algo 

1) Me^a, melhore, me^a — Para a aplica^ao ou o codigo mais critico que voce man- 
tem, fa^a uma lista de fatores mensuraveis que representam a qualidade da apli- 
ca^ao. Isso pode ser o tempo de resposta, numero e exce^oes nao tratadas que sao 
lan^adas durante o processamento, ou tempo de atividade da aplica^ao. Ou, se 
voce cuida do suporte, nao avalie diretamente a qualidade da aplicacao. O tempo 
que voce leva para responder ao chamado e uma parte importante da experiencia 
do usuario com a aplicacao. 

Escolha os mais importantes desses atributos mensuraveis, e comece a medi-los. 
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Depois que voce tiver uma boa base, estabele^a um objetivo realista e melhore 
a performance da sua aplica^ao (ou sua propria performance) para alcan^ar esta 
meta. Depois de ter feito uma melhoria, me^a mais uma vez para verificar que 
voce realmente fez a melhoria desejada. Se sim, compartilhe isso com sua equipe 
e seus clientes. 

Escolha uma outra metrica e fa^a isso mais uma vez. Depois da primeira, voce 
descobrira que isso se torna divertido, como um jogo. Aprimorar coisas de modo 
mensuravel como este se torna viciante. 
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Maratona de oito horas 


Uma das diversas fontes de controversia a respeito do movimento Extreme Program¬ 
ming e sua declaraijao inicial de que os membros da equipe nao deveriam trabalhar 
mais que quarenta horas por semana. Esse tipo de conversa realmente contraria ge- 
rentes escravocratas que querem espremer o maximo de produtividade possivel de 
suas equipes. Isso pode chatear ate mesmo os programadores. O numero de horas de 
trabalho continuo se torna parte da masculinidade do desenvolvedor, como quantas 
cervejas alguem pode virar em uma cervejada. 

Bob Martin (http://www.objectmentor.com) , um dos grandes nomes da comu- 
nidade de Extreme Programming, inverteu essa senten^a de tal forma que a tornou 
muito mais toleravel por ambas as partes, enquanto ainda se mantinha fiel ao intento 
original de Kent Beck. Martin renomeou quarenta horas de trabalho semanais para 
“maratona de oito horas”. A ideia e que voce deveria trabalhar com tanto afinco que 
nao seria possivel continuar por mais tempo do que oito horas. 

Antes de voce mergulhar na maratona, por que a enfase em manter o numero 
de horas baixo de qualquer maneira? Este capitulo e sobre terminar coisas. Nao 
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deveriamos estar conversando sobre trabalhar por mais horas? 

Quando se trata de trabalho, menos realmente pode ser mais. O primeiro motivo 
citado pelos Extreme Programmers e que, quando estamos cansados, nao consegui- 
mos pensar tao efetivamente quanto quando estamos descansados. Quando estamos 
esgotados, nao somos tao criativos, e a qualidade do nosso trabalho se reduz drama- 
ticamente. Come^amos a cometer erros estupidos que acabam nos custando tempo 
e dinheiro. 

Projetos sao maratonas, nao corridas de velocidade. 


A maioria dos projetos dura bastante tempo. Voce nao consegue manter o ritmo 
de um arranque e terminar uma maratona. Embora sua produtividade a curto prazo 
va aumentar significativamente conforme conta as horas, a longo prazo voce vai de- 
cair tao gravemente que o tempo de recupera^ao sera mais longo do que os ganhos 
de produtividade que voce aproveitou durante suas semanas de oito horas. 

Voce tambem pode pensar em seu tempo da mesma maneira que voce pensa de 
seu dinheiro. Quando eu era um adolescente, trabalhava meio periodo por salario 
minimo. Eu teria sido muito feliz se tivesse a quantidade de dinheiro que eu gasto 
agora. Eu tenho tanto mais dinheiro agora do que quando adolescente, que eu tendo 
a ser menos consciente com como eu gasto cada dolar. De alguma forma, eu conse- 
guia sobreviver naquele tempo. Eu tinha um lugar para viver, um carro para dirigir, 
e comida para comer. 

Eu tenho as mesmas coisas hoje. E eu nao tenho um estilo de vida particular- 
mente extravagante agora. Aparentemente, quando dinheiro era escasso, eu dava 
um jeito de ser mais eficiente com o que eu ganhava. E o resultado final era essenci- 
almente o mesmo. 

Nos tratamos os recursos escassos como sendo mais valiosos, e fazemos uso mais 
eficiente deles. Somando-se a questao de dinheiro, podemos aplicar isso para nosso 
tempo. Pense no quarto dia da sua ultima semana de setenta horas de trabalho. Sem 
duvidas, voce estava realizando fazendo um baita esforcjo. Mas a partir do quarto 
dia, voce come^a a afrouxar. Sao 10I130 da manha, e eu sei que estarei aqui por 
quatro horas depois que todos os outros vao para casa. Quer saber, acho que vou 
dar uma olhada nas ultimas noticias de tecnologia. 

Quando voce tern muito tempo para trabalhar, seu tempo de trabalho se reduz 
significativamente em valores percebiveis. Se voce tern setenta horas disponiveis, 
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cada hora e menos preciosa para voce do que quando voce tem quarenta horas dis- 
poniveis. 

Quando o valor do dolar sofre uma inflaijao, sao necessarios mais dolares para 
comprar a mesma coisa. Quando o valor da hora e deflacionado, voce precisa de 
mais horas para fazer coisas. A maratona de oito horas de Bob Martin estabelece 
uma limita^ao e lhe oferece uma estrategia para lidar com essa restricpao. Voce vai 
trabalhar e pensa: Eu so tenho oito horas! Vai, vai, vai! Com barreiras estreitas 
nos horarios de initio e fim, voce naturalmente come^a a organizar seu tempo mais 
eficazmente. Voce pode come^ar com um conjunto de tarefas que precisam ser con- 
cluidas no dia, organiza-las em ordem de prioridade, e come^ar a finaliza-las uma 
de cada vez. 

A maratona de oito horas cria um ambiente que se parece com aquele final de se- 
mana ultraprodutivo que voce possivelmente teve na epoca da faculdade, estudando 
para uma prova de uma materia que voce nao estava nem ai ou deixando de lado um 
trabalho para a ultima hora por pura preguicja. A diferen^a e que este e um acumulo 
limitado. Esses momentos em que voce corre atras sao extremamente produtivos, 
porque o tempo se torna escasso e, portanto, bastante valioso. A maratona de oito 
horas e um metodo de estar sobrecarregado frequentemente, sem ter que ficar acor- 
dado a noite inteira a base de Ritalina e bebendo Coca Cola. 

Como trabalhadores mentais, mesmo se nao estamos na frente de um compu- 
tador ou no escritorio, podemos estar trabalhando. Voce pode estar trabalhando 
enquanto dirige para jantar com sua esposa ou enquanto voce assiste a um filme. 
Seus deveres ficam seguindo-o e incomodando-o. 

Meu trabalho geralmente me incomoda quando eu nao prestei aten^ao suficiente 
a ele. Posso ter deixado alguma tarefa escapar ou deixado-as acumular, nao cuidado 
delas. E esse o momento que o trabalho me persegue ate em casa e me cutuca quando 
tento relaxar. Se seu trabalho se intensifica todo dia, voce vai descobrir que ele nao 
o persegue ate em casa. Nao somente voce esta deliberadamente se impedindo de 
trabalhar horas-extras, mas sua mente vai realmente permitir que voce pare de fazer 
horas-extras. 

Fa^a o orijamento de seu trabalho cuidadosamente. Trabalhe menos, e voce rea- 
lizara mais. Trabalho e sempre mais bem-vindo quando voce se deu um tempo longe 
dele. 

Fa$a algo 
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1) Certifique-se de que voce durma bem hoje. Amanha, tome o cafe da manha e, 
entao, comece a trabalhar em um horario exato (de preferencia, um pouco mais 
cedo que ousual). Trabalheintensivamente por quatro horas. Tire umahorapara 
almo^ar. Entao, trabalhe por mais quatro horas tao intensamente que voce fique 
absolutamente exausto e nao consiga fazer mais. Va para casa, relaxe, e divirta-se. 
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Como programadores, sabemos que, quanto mais cedo no processo de desenvolvi- 
mento conseguimos descobrir falhas de software, mais robusto ele vai ficar. Testes 
de unidade nos ajudam a desentocar erros estranhos o mais cedo possivel. Se encon- 
trarmos erros bizarros em nosso codigo, e se isso acontecer cedo, ficaremos felizes. 
Embora eles signifiquem uma pequena falha em nosso papel como desenvolvedores 
- afinal cometemos uma falha de programa^ao - descobri-los cedo e frequentemente 
e um bom sinal da saude do software que voce vai ter. 

Somos ensinados a permitir que nossos erros de programa^ao sejam grandes e 
bagun^ados desde cedo. Voce quer saber quais eles sao e em qual momento eles 
acontecem, para que voce fa<;a as corre<;6es necessarias. Quando voce esta escre- 
vendo codigo, voce nao desvia do seu caminho para esconder as pequenas falhas de 
software que estao destinadas a aparecer durante o desenvolvimento. Esta e a forma 
de o codigo conversar com voce. Aquelas pequenas falhas sao parte do processo de 
fortalecimento do software. 

As pequenas falhas que encontramos tambem nos ensinam que tipo de falhas 
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esperar. Se voce nunca andou em um campo minado antes, voce pode nao saber as 
protuberancias ou sujeiras nas quais nao pisar. Se seu software nao tem dado erro re- 
gularmente, voce pode nao saber onde os problemas podem estar. E alem disso, voce 
pode ate programar muito defensivamente, colocando diversas verifica^oes, mas se- 
ria o mesmo que se estivesse programando as cegas. 

Alem disso, claro, e importante programar defensivamente. A qualidade do soft¬ 
ware e realmente colocada a prova quando as coisas dao errado. E inevitavel que al- 
guma coisa vai acontecer para um cenario que voce nao percebeu. Seg-faults e telas 
azuis em produ^ao mostram que os programadores nao fizeram um bom trabalho 
de lidar com as situates que eles nao puderam prever. 

Os mesmos principios se aplicam ao emprego. Alguem que faz trabalhos ma¬ 
nuals e realmente colocado a prova quando surgem os erros. Aprender a lidar com 
os erros e uma habilidade altamente valiosa e dificil de se ensinar. Como musico 
improvisador de jazz, aprendi que toda nota errada e no maximo um tom distante 
de uma nota certa. O que torna os improvisos ruins e quando o improvisador nao 
sabe o que fazer quando a nota errada aparece. Com uma banda de um lado e o pu¬ 
blico do outro, o som de uma nota errada e suficiente para travar um amador. Ate os 
mestres tocam notas erradas. Mas eles se recuperam de tal forma que o ouvinte nao 
consegue notar se a coisa toda nao foi intencional. 

Todos nos vamos cometer erros estupidos no trabalho. Faz parte do ser humano. 
Cometemos erros que fazem os clientes verem stack traces. Nos nos penitenciamos 
quando cometemos erros graves de design. Ou, pior ainda, dizemos as coisas erradas 
para as pessoas da nossa equipe, chefes e clientes. Tra^amos maus compromissos ou 
fazemos afirma^oes falsas sobre o que somos capazes de fazer. Ou acidentalmente 
damos um mau conselho a equipe sobre como resolver um problema tecnico, des- 
perdi^ando horas de seu tempo. 

Porque todos nos cometemos erros, e tambem sabemos que todo mundo comete 
erros. Logo, com razao, nao julgamos uns aos outros nos erros que cometemos. 
Julgamo-nos sobre como lidamos com esses erros inevitaveis. 

Seja um erro tecnico, de comunica^ao, ou de gerencia de projeto, as seguintes 
regras podem ser aplicadas: 

• Levante o assunto logo que souber. Nao tente esconder. Em desenvolvimento 
de software e testes, erros descobertos antes sao um problema menor do que 
erros descobertos tarde. O mais cedo que voce expuser o que tiver feito, menos 
negativo o impacto deve ser. 
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• Leve a culpa. Nao tente procurar por um bode expiatorio mesmo se voce en- 
contrar um que sirva. Mesmo se a culpa nao for completamente sua, assuma 
a responsabilidade e continue em frente. O objetivo e passar desse ponto o 
mais rapido posslvel. Um problema precisa de uma resolu^ao. Prolonga-lo 
discutindo de quern e a culpa apenas atrasa a solu^ao. 

• Ofere^a uma solu^ao. Se voce nao possui uma, ofere^a um piano de ataque 
para descobrir uma solu^ao. Fale em termos concretos e prazos previslveis. 
Se voce tiver conduzido sua equipe a um canto, de prazos para quando voce 
retornara com a avalia^ao do esfor^o necessario para corrigir o problema. Me- 
tas concretas e alcan^aveis, mesmo se pequenas e imateriais, sao importantes 
nesse estagio. Nao apenas elas mantem as coisas em funcionamento, de mau 
para bom, mas tambem ajudam a reconstruir a credibilidade no processo. 

• Pe<;a ajuda. Mesmo se voce for o unico culpado de um problema, nao deixe seu 
orgulho piorar a situa^ao, recusando ajuda em uma solu^ao. Os membros de 
sua equipe, chefes e clientes vao olhar para voce de um angulo mais positivo se 
voce conseguir manter uma atitude saudavel e deixar seu ego de lado enquanto 
a equipe ajuda a encontrar a saida. Muito frequentemente, sentimos um senso 
de responsabilidade que nos faz suportar orgulhosamente um fardo pesado 
demais, e acabamos travados ate que alguem intervenha. 

Pense na ultima vez em que voce teve um problema em um restaurante. Talvez 
voce esperou demais ate o prato errado finalmente chegar a sua mesa. Pense sobre 
como o gar^om reagiu a sua reclama^ao. 

Momentos de estresse oferecem as melhores oportunidades de construirfidelidade. 


A rea^ao errada seria se o gar^om desse desculpas ou culpasse os cozinheiros. 
A reacjao errada seria o gar^om sair andando e reenviar o pedido, e ficar fora do 
seu campo de visao por um tempo, enquanto voce continua la com fome e pensando 
quando e que sua comida vai chegar. Claro, a rea^ao realmente errada seria o gar^om 
chegar com um prato que ele ja sabe que e o errado, esperando que voce nao repare 
ou nao reclame. 

A diferen^a entre como uma empresa nos trata quando houve um erro pode ser a 
ultima palavra em construir fidelidade (ou destruir). Um erro com o qual for bem li- 
dado pode tornar-nos consumidores mais fieis do que seriamos se nunca tivessemos 
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experienciado o problema de service). Lembre-se disso com seus clientes quando 
cometer erros no trabalho. 
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O jeito mais facil de nao cumprir com seus compromissos e se comprometer com o 
que voce sabe que nao conseguira cumprir. Eu sei que, evidentemente, isso soa obvio, 
mas nos fazemos isso todo dia. Estamos a vista de todos e nao queremos desapontar 
nossos lideres, entao aceitamos o compromisso de realizar trabalhos impossiveis em 
prazos inviaveis. 

Dizer “sim”para evitar desapontamento e apenas mentir. 


Dizer “sim” e um habito viciante e destrutivo. E um mau habito mascarado como 
bom. Mas existe uma grande diferen^a entre uma atitude “posso fazer” e a deturpa- 
$ao da capacidade de alguem. Esta ultima causa problemas nao apenas para voce 
mas para as pessoas para quern voce esta fazendo promessas. Se eu sou seu gerente 
e pergunto se voce pode reescrever o modo como rastreamos remessas no sistema 
da empresa ate o fim do mes, e provavel que eu tenha perguntado especificamente 
sobre o fim do mes por alguma razao. Alguem provavelmente perguntou a mim se 
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isso poderia ser feito ate la. Ou deve haver outra mud am; a critica de negocios que 
estamos tentando fazer que depende do sistema. Entao, munido de sua garantia de 
que voce pode conseguir nesse prazo, eu saio e falo aos meus clientes que isso sera 
feito. 

Dizer “sim” desse jeito e tao bom quanto mentir. Nao estou dizendo que e malici- 
oso. Nos mentimos para nos mesmos tanto quanto para aquelas pessoas com quern 
nos comprometemos. Afinal, dizer “nao” nos faz sentir mal. Somos programados a 
sempre querer obter sucesso. E, dizer que nos nao conseguimos fazer alguma coisa 
da a sensa^ao de que falhamos. 

O que nos, humanos, nao conseguimos absorver e que “sim” nao e sempre a 
resposta certa. E “nao” e raramente a resposta errada. Eu digo absorver, porque eu 
acho que todos nos sabemos que isso e verdade. Afinal, nenhum de nos quer receber 
falsos compromissos. 

A inabilidade de dizer “nao” e uma parte comum da cultura indiana. Empre- 
sas sem experiences em terceiriza<;6es offshore quase sempre vao em direcjao a isso. 
Voce aprende com o tempo a farejar incertezas e faz as perguntas certas. Conver- 
sas do tipo “mais um dia para isso estar pronto” naturalmente o treinam a sondar 
mais profundamente. E isso nao e apenas parte da cultura de TI. Quando morei em 
Bangalore, deixei de ir ao trabalho e fiquei em casa nao menos do que cinco vezes, 
a espera de uma instala<;ao do modem a cabo que nunca aconteceu. Nas primeiras 
tres vezes, a empresa nem possuia os aparelhos necessarias para a instala^ao quando 
fizeram o agendamento. Mas eles nao queriam me desapontar. Eu disse que espe- 
rava ter o modem instalado ate a proxima semana, entao eles me prometeram que 
a instala^ao seria feita, sabendo muito bem que isso nao ia ser possivel na proxima 
semana. 

Embora a inten^ao fosse boa, as ramifica<;6es foram negativas. Eu eventualmente 
fui desagradavel com os instaladores e ate mesmo fiz com que viessem a minha casa 
para fazer a instala^ao em um feriado. Nao confiei na promessa de que o fariam 
“amanha, depois do feriado”. O fato de terem falhado repetidamente com seus com- 
prometimentos destruiu qualquer possibilidade que eu tinha de confiar neles. Alem 
disso, eu fui desenvolvendo uma atitude de hostilidade em rela^ao a eles. 

Por outro lado, o que acontece quando lhe pedem que fa<;a uma tarefa critica e 
voce diz que nao pode? Como gerente tanto de equipes onshore como de offshore, 
posso lhe dizer que “nao” se tornou uma fonte de alivio para mim. Se um membro 
da equipe tern a coragem de dizer “nao” quando esta e a verdade, entao eu sei que 
quando eles dizem “sim”, eles realmente querem dizer isso. Um comprometimento 
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de uma pessoa assim sera mais creditavel e tera mais peso. Se eles realmente alcan^a- 
rem seus objetivos com os quais se comprometeram, nao vou questiona-los quando 
disserem que nao podem alcan^ar outro. 

Se alguem sempre diz “sim”, ele e ou incrivelmente talentoso ou esta mentindo. 
Este ultimo e geralmente o caso. 

“Eu nao sei” tambem e uma otima coisa a dizer quando apropriado. Essa pode 
ser uma resposta para se voce consegue cumprir tal prazo e precisa de tempo para 
pesquisar a tarefa antes de estabelecer qualquer compromisso. Ou voce pode ser 
questionado sobre como uma tecnologia funciona ou como alguma parte do codigo 
do seu projeto e implementada. Assim como no caso dos comprometimentos, nao 
saber a resposta de algo da a sensa^ao de uma pequena falha. Mas seus colegas de 
trabalho e seus chefes terao mais fe em voce quando voce alegar saber alguma coisa. 
Voce notara que, quando encontrar um guru real em determinada area, ele nunca 
tera medo de admitir quando nao sabe algo. “Eu nao sei” nao e uma frase para gente 
insegura. 

A mesma coragem tambem pode aparecer convenientemente quando estiver li- 
dando com decisoes vindas de cima. Quantas vezes voce viu uma decisao de tecno¬ 
logia ditada por um chefe que fez os membros da equipe sentarem ao redor da mesa 
silenciosamente olhando para seus sapatos e esperando uma chance para escapar da 
sala de reuniao, para poderem reclamar uns com os outros? Gerentes sao geralmente 
o alvo do fenomeno A roupa nova do rei ( Emperor’s New Clothes). Todo mundo sabe 
que uma decisao e ruim, mas todos estao com medo de se pronunciar. Entretanto, 
eu nao contrato meus funcionarios para serem robos. Sao os que se pronunciam e 
oferecem uma sugestao melhor que se tornam meu acessores confiaveis. 

Nao va muito alem com o jogo do “nao”. Atitudes de “poder fazer” ainda sao 
bem-vindas, e e bom ter metas ambiciosas. Se voce nao tern certeza se consegue 
fazer alguma coisa, mas quer tentar, diga isso. “Isso sera um desafio, mas eu gostaria 

de tentar” e uma resposta maravilhosa. As vezes, e claro, a resposta e simplesmente 

« • » 
sim. 

Tenha coragem o suficiente para ser honesto. 

Fa9a algo 

1) Karl Brophey, um critico, sugere manter uma lista de tudo o que voce se compro- 
meteu: 

• O que foi pedido com uma data limite? 
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• Com o que voce se comprometeu? 

• Se voce esta atrasado, registre tanto o que voce fez e o que lhe mandaram 
fazer. 

• Registre quando voce cumpriu o dever. 

Examine isso diariamente. Comunique quando voce falhara assim que voce per- 
ceber. Examine isso mensalmente — qual sua media de sucesso? Com qual 
frequencia voce esta correto? 


132 
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Nao entre em panico 


Eu comecei minha carreira de programador por causa de video games. Desde a epoca 
dos cartuchos com meu Commodore 64, eu fui conquistado pelas experiences imer- 
sivas e interativas. Eu costumava ter vergonha de admitir isso, mas agora percebo que 
nao e nada para se envergonhar. Para mim, jogos de computador fizeram do ambi- 
ente on-screen (do sistema operacional, eu acho) um ambiente em que eu me sentia 
confortavel e disposto. 

Meu jogo favorito de todos os tempos era Doom, da ID Software. Eu era apai- 
xonado pelas modos de one-on-one, jogador vs. jogador e combates mortals. Os 
jogadores se conectavam via modem ou conexao serial, e lutavam entre si em um 
pequeno e acelerado ambiente. Eu fiquei bom nos combates mortals do Doom. Eu 
dizia que isso devia ser o que eu melhor sabia fazer da minha vida. O jogo de com- 
bate mortal e surpreendentemente complexo. E tanto tecnico como psicologico — 
como uma mistura frenetica de xadrez e esgrima. 

Assim como para a maioria das habilidades, uma otima maneira de se tornar 
bom e assistir os mestres. La na minha epoca de Doom, havia um mestre que possuia 
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o pseudonimo ironico de “Noskill” (Sem habilidades, em ingles). Noskill era, de 
fato, o campeao de Doom. Pessoas dos Estados Unidos e Canada pagavam tarifas 
telefonicas de longa distancia para tentar a sorte contra ele. Esses combates eram 
gravados. Eu assistia a todos. 

Nao levou muito tempo para eu aprender seu segredo. Claro, no geral ele era 
bom no jogo, mas havia uma chave obvia para seu sucesso: ele nunca entrava em 
panico. Doom era o tipo de jogo em que uma partida podia terminar em, literal- 
mente, segundos depois de come^ar. Era realmente rapido. Eu me lembro do meu 
primeiro jogo de combate mortal. Come^a, morre, come^a, morre, come^a, morre. 
Quando eu finalmente consegui bear vivo por mais do que dois segundos, peguei-me 
correndo sem rumo, mal sendo capaz de acompanhar onde eu estava. 

Mas Noskill nunca agia dessa forma. Nao importava quao dificil era a situa^ao, 
voce podia notar ao assistir as grava^oes que ele estava sempre relaxado e sempre 
pensando no que fazer em seguida. Ele sempre aparentava estar ciente de como seu 
contexto atual se encaixava no formato geral da partida. 

Herois nunca entram em panico. 


Agora, se voce pensar em outros jogos, em particular esportes, voce vai reco- 
nhecer que todos os melhores jogadores compartilham dessa qualidade. Alias, ate 
mesmo os personagens que admiramos nos livros, na televisao e nos filmes compar¬ 
tilham dessa qualidade. Herois nunca entram em panico. Eles sao sempre as pessoas 
que podem ter uma bomba nuclear caindo sobre sua cidade, ou ter um acidente de 
aviao, e conseguem organizar um grupo, ajudar os sobreviventes, ser mais esperto 
que o inimigo, ou pelo menos, apenas nao se desabar em lagrimas. 

Isso se estende a vida real tambem. Apesar do meu melhor planejamento, mi- 
nha vida profissional tern sido uma corrente de emergences e desastres. Projetos 
sao concluidos bem tarde. Softwares dao problemas, custando dinheiro e credibili- 
dade dos meus chefes. Eu digo a coisa errada para o vice-presidente errado e ganho 
um inimigo politico. Na maioria das vezes, essas coisas vem em ondas todas juntas, 
nunca uma por vez. 

Em meus piores momentos, eu entro em panico. Eu travo e, na melhor das hipo- 
teses, consigo pensar taticamente. Reajo a cada pequeno movimento sem a clareza 
de considerar o grande cenario. 

Mas olhando para tras para, literalmente, cada desastre, nenhum teve um im- 
pacto duradouro e notavel em mim ou em minha carreira. Portanto, por mais que 
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eu tenha ficado em panico, depressivo ou chateado nessas situates aparentemente 
desastrosas, nenhuma foi realmente um verdadeiro desastre. 

O que o panico trouxe para mim? Qual foi a vantagem de reagir negativamente 
para cada uma dessas situates? Nada. O que o panico realmente me deu foi uma 
inabilidade de agir no meu melhor nas vezes em que eu realmente precisava dar o 
meu melhor. 

Agora eu tenho que admitir que nao entrar em panico em situates estressantes 
e mais facil de se dizer do que fazer. E quase como dizer para alguem: “simplesmente 
seja feliz”. E claro, e um bom conselho, mas como se faz isso? Como voce evita entrar 
em panico quando as coisas parecem estar desabando? Para responder esta questao, 
talvez ajude pensar um pouco sobre por que nos entramos em panico. 

Nos entramos em panico porque perdemos perspectiva. Quando algo tern dado 
errado, e dificil nao focar toda nossa aten^ao no problema. De certa maneira, esse 
e um bom jeito de resolver problemas. Infelizmente, isso tambem faz o problema, 
nao importa quao pequeno seja, aparentar ser mais importante do que realmente e. 
E com o problema aumentando, e os niveis de estresse la em cima, nossos cerebros 
se desligam. 

Quern e o pior usuario de computador que voce conhece? Para mim, e prova- 
velmente um dos meus sogros (eu sei quern, mas sou esperto o suficiente para nao 
dar nomes aqui). Imagine aquela pessoa sentada com seus computadores tentando 
terminar um projeto quando uma mensagem de erro come^a a aparecer com qual- 
quer coisa que eles tentam fazer. Todos nos ja vimos isso acontecer. Usuarios sem 
experiencia ficam rapidamente frustrados e se desesperam. Entao come (jam a fre- 
neticamente clicar e arrastar coisas pela tela, ignorando as mensagens que potenci- 
almente os poderiam ajudar conforme elas continuam aparecendo repetidamente. 
Eles eventualmente ficam tao afobados que precisam pedir ajuda, mas geralmente 
nao antes de bagumjar uma ou duas coisas adicionais no computador. 

Nao me leve a mal, mas eu quero que voce imagine essa situacjao com alguem 
que voce conhecja, que seja apropriado para o papel principal, e quero que voce ria 
disso. Esse tipo de comportamento e realmente ridiculo, nao? E comico. 

Mas, por mais genuinamente engraijado que isso seja, o que nos acabamos de 
imaginar foi um cenario da vida real em que uma pessoa, trabalhando fora de sua 
zona de conforto, encontra um problema e entra em panico. Nao e diferente da forma 
como eu reagi quando projetos se atrasaram ou eu acidentalmente causei um bug no 
sistema, ou desapontei um cliente. E apenas um contexto diferente. 

Entao, aqui esta como eu estou aprendendo a nao entrar em panico. Quando 
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algo ruim acontece, e eu comedo a sentir aquela sensa^ao estressante de afundar 
que me levaria ao panico, eu me comparo aquele frustrado usuario de computador 
inexperiente, e rio de mim mesmo. Eu analiso a situa^ao pela perspectiva da terceira 
pessoa, como se eu estivesse ajudando aquele membro da famllia que esta frustrado 
com seu desastre. Problemas aparentemente dificeis tornam-se repentinamente mais 
faceis. Situates aparentemente ruins de repente nao sao tao ruins. E eu sempre 
encontro a solu^ao simplesmente olhando na minha cara, da mesma forma que a 
caixa de dialogo de erro geralmente lhe diz exatamente o que voce deve fazer. Se 
voce apenas tiver a presen^a de espirito para ler a mensagem de erro, o problema 
pode ser solucionado. 

Fa£a algo 

1) Mantenha um diario do panico. A chave para capturar o panico antes que ele 
aconte^a e desenvolver uma consciencia intensificada em tempo real de suas per- 
cep^oes e emo^oes conforme elas acontecem. Eu tirei a sorte grande ao aprender 
a fazer isso analisando minhas reaches a situates depois do fato. Eu nao sou 
esperto o suficiente para manter uma linha constante de analise dos meus pen- 
samentos conforme eles acontecem, mas eu descobri que se eu praticar a analise 
“offline”, eu melhoro cada vez mais para realiza-la em tempo real. 

Dizer que voce se empenhara mais em analisar suas rea^oes e realmente fazer isso 
sao duas coisas bastante diferentes. Manter um diario vai ajuda-lo a adicionar 
estrutura ao processo. Todo dia, em um horario especifico (use um calendario 
como um lembrete!), abra um arquivo de texto e registre qualquer situa^ao que 
o levou a sentir panico, mesmo se foi pouco. Uma vez por semana, veja a lista da 
semana passada e mantenha um estoque dos ultimos impactos de cada situa^ao 
que induziram ao panico. A situa^ao valeu o panico? Qual teria sido a rea^ao 
mais produtiva para a situa^ao? O que um heroi, em um filme dramatico sobre 
sua vida, teria feito em vez de entrar em panico? 

Depois de alguma pratica, voce descobrira que a analise come^a a acontecer en- 
quanto o panico emerge. Conforme voce racionalmente explora as razoes do seu 
panico em tempo real, voce descobrira que o panico, por si proprio, vai para o 
banco de tras, e eventualmente se dissipa. 
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Diga, fa^a, mostre 


O jeito mais facil de nunca tornar algo pronto e nunca se comprometer com nada. 
Se voce nao tem um prazo, nao ha nenhuma pressao ou incentivo suficiente para 
concluir algo. Isso e ainda mais verdadeiro quando esse algo que deve ser feito nao 
e 100% excitante. 

O instinto de, ate mesmo, um mau gerente geralmente diz que e importante pla- 
nejar. Para alguns desenvolvedores, a invoca^ao da palavra planejamento e motivo 
de alarme. Reunioes interminaveis com seus chefes criando e analisando graficos 
do Microsoft Project, que ninguem entende ou usa, sao uma causa valida de alarme. 
Entao, os tecnologos geralmente tentam compensar, como rebeliao contra o excesso 
de planejamento, agindo conforme suas proprias decisoes, em vez das que foram 
estabelecidas no piano. 

Planejamento nao e um remedio tao ruim, daqueles que precisamos tampar o 
nariz para engolir. Ele pode ser uma experiencia libertadora. Quando voce tem 
muito a fazer, um piano pode fazer a diferen^a entre um comedo de dia de trabalho 
confuso e ambiguo, e a confian^a de uma mente limpa ao atacar as tarefas. 
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Pianos nao precisam ser grandes e prolongados. Uma lista em um documento 
de texto ou um e-mail e perfeitamente suficiente. Pianos nao precisam cobrir um 
longo espa^o de tempo. A possibilidade de come^ar o dia e responder a questao “O 
que voce vai fazer hoje?” e um otimo primeiro passo. Conheijo muitas pessoas cujos 
dias come^am tao agitados que eles provavelmente falhariam nesse teste. Um bom 
primeiro passo seria achar tempo nessa tarde e listar tudo que voce quer concluir 
no proximo dia de trabalho, e organizar em uma lista de prioridades. Tente ser re- 
alista quanto ao que pode fazer em um dia, embora seja provavel que voce erre e se 
sobrecarregue. 

Voce pode ser tao detalhista ou vago quanto quiser com seu piano de um dia. Eu 
tive um colega de quarto na faculdade chamado Chris que acordava todas as manhas 
e, mesmo com o risco de se atrasar para sua primeira aula, planejava meticulosa- 
mente seu dia, especialmente com foco em seu horario de praticar piano (ele estava 
cursando piano e jazz). Sua agenda ja era bastante rigida com a sele^ao de aulas que 
ele tinha que frequentar. Mesmo assim, Chris realmente fazia um piano sobre como 
ele poderia usar aqueles quinze minutos entre as aulas para encaixar sua rotina de 
treinos que podiam ser feitos rapidamente. 

Muitas de suas aulas eram no mesmo predio, de modo que era comum ter bas¬ 
tante tempo de lazer entre elas para socializar ou pegar alguma bebida nas maquinas. 
Nesse tempo, Chris preferia se dedicar as escalas ou a treinar sua audicjao, enquanto o 
resto de nos ficava sentado esperando a proxima aula come^ar. Ele ate mesmo dividia 
seu horario em multiplos segmentos de tres a cinco minutos, para poder treinar mais 
de um exercicio em um dado periodo de dez minutos. O Chris acabou se tornando 
um dos musicos mais respeitados em nossa cidade. Claro que o talento natural tinha 
algo a ver com isso, mas desde entao eu tenho a cren^a de que ele planejou e executou 
seu caminho para a elite musical. 

Entao, voce fez seu planejamento. Pode nao ser tao detalhado como o do Chris, 
mas e o suficiente para responder a pergunta de o que voce vai fazer com seu dia. 
Quando voce for trabalhar amanha, pegue a lista e comece o primeiro item. Trabalhe 
pela lista ate o almo^o, e depois continue de onde parou e tente conclui-la. 

A medida que voce completa cada item da lista, marque “FEITO”. Use letras 
maiusculas. Esteja feliz. Ao fim do dia, olhe para sua lista de coisas FEITAS e sinta 
que voce conquistou alguma coisa. Nao apenas voce sabia o que ia fazer nesse dia, 
mas agora voce sabe que o fez. 

Se voce nao concluiu tudo, nao se preocupe. Voce sabia que nao estaria certo 
em rela<pao a quanto caberia em um dia de qualquer forma. Apenas mova os itens 
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incompletos de hoje (se ainda forem relevantes) para a lista de amanha, e comece 
o processo de novo. E um processo estimulante. E ritmico. Isso permite que voce 
divida seus dias e semanas em series de pequenas vitorias, cada uma incentivando- 
lhe para a outra. Voce descobrira que isso nao apenas lhe da visibilidade para o que 
esta conquistando, mas lhe dara, na verdade, mais feitios do que se voce nao estivesse 
olhando as coisas tao de perto. 

Uma vez estabelecido um ritmo de pianos e ataques, voce esta pronto para co- 
me^ar a pensar em termos de semanas e ate mesmo meses. E claro, quanto mais 
comprido for o espa^o de tempo para o qual voce esta planejando, maior o nivel que 
seu planej amenta deve ter. Pense nos pianos diarios e semanais como pianos de ba- 
talhas taticas, com pianos de trinta, sessenta, e noventa dias focando em objetivos 
mais estrategicos que voce quer alcan^ar. 

O proprio ato de pensar sobre o que voce quer alcan^ar em noventa dias e algo 
nao natural desenvolvedores de software. 

Nos somos pessoas taticas. Forijar-se a imaginar um estado final para seu sis- 
tema, para o processo de sua equipe, ou de sua carreira depois de noventa dias vai 
trazer coisas a tona que voce nunca esperaria. O campo, visto de cima, mostra-nos 
varias coisas diferentes do que a visao do chao. E dificil no comedo, mas mantenha-se 
firme a isso. Como todas as boas habilidades, isso se torna mais facil com a pratica, 
e os beneficios serao visiveis tanto para voce como para aqueles que trabalham com 
voce (mesmo se eles nao sabem o que voce esta fazendo). 

Relatorios de status podem ajuda-lo a se vender e mostrar resultados. 


Voce deveria come^ar a comunicar seus pianos para seus chefes. O melhor mo¬ 
menta para isso e depois de ter executado pelo menos um ciclo do piano. E — este 
e um ponto importante — comece a fazer isso antes de eles lhe pedirem. Nenhum 
chefe em sa consciencia ficaria chateado ao receber um e-mail semanal sucinto de 
um funcionario, estabelecendo o que foi feito na semana anterior e o que esta plane- 
jado para a proxima. Receber esse tipo de mensagem regular nao solicitada e a paz 
de todo chefe. 

Comece comunicando-se semana por semana. Quando voce estiver confortavel 
com esse procedimento, comece a trabalhar em pianos de trinta, sessenta e noventa 
dias. 

A longo prazo, concentre-se no progresso mais alto nivel e impactante que voce 
deseja aplicar em seus projetos ou nos sistemas que voce mantem. Sempre estabele^a 
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esses planejamentos como propostas para seu chefe, e pei;a por feedback. Com o 
tempo, essas tentativas de antecipa^ao vao requerer menos puxoes de orelha dos seus 
chefes, conforme voce aprende quais itens geralmente nao precisam ser editados e 
quais sao assuntos que precisam de mais aten^ao. 

O fator mais critico para se ter em mente com tudo que vai em um planejamento 
e que tudo deve ser contabilizado depois. Cada item deve estar ou visivelmente al- 
can^ado, atrasado, removido, ou substituido. Nenhum item pode estar fora dessas 
categorias. Se itens aparecem em um piano, e nunca sao mencionados de novo, as 
pessoas vao parar de confiar em seus pianos, e voce estara indo contra a eficacia do 
planejamento. Mesmo se o resultado e ruim, voce tambem deve comunica-lo. To- 
dos nos cometemos erros. O jeito de se diferenciar e tornar publicos seus erros e 
inabilidades, e pedir ajuda para resolve-los. Seguir consistentemente as tarefas de 
um piano vai gerar a merecida impressao de que nenhum trabalho importante esta 
se perdendo no meio. 

Mantenha esse procedimento e de repente, aos olhos de seu chefe, voce expos 
seu lado estrategico. Criar e executar pianos demonstra que voce nao e apenas um 
robo que digita codigos, mas que voce e um lider. E esse tipo de produtividade 
independente que as empresas precisam conforme elas reduzem a sobrecarga. 

Um beneficio final de comunicar seus pianos e que seus comprometimentos ga- 
nham mais credibilidade. Se voce disser que voce vai fazer algo, e realmente o faz e 
o mostra pronto, voce desenvolve a reputa^ao de ser um cumpridor. Com credibi¬ 
lidade vem a influencia. Imagine que voce queira introduzir um novo processo, tal 
como uma pratica de desenvolvimento agil, em sua empresa, ou entao voce quer tra- 
zer uma nova tecnologia. Com sua habilidade comprovada de estabelecer e alcan^ar 
compromissos, vao conceder-lhe mais liberdade para tentar coisas novas. 

Em nosso centra de software de Bangalore, tinhamos uma equipe que trabalhou 
em turnos da noite por mais de um ano. Dos sete membros da equipe, dois estavam 
sempre no turno da noite. Eles revezavam semanalmente, de modo que toda terceira 
ou quarta semana, cada membra mudaria para o horario das 19I1 as 3I1 da manha. A 
equipe estava cada vez mais frustrada e esgotada. Mas a equipe estava atuando em 
um papel de apoio crucial, e os clientes internos que ficavam nos Estados Unidos 
estavam convictos de que nao conseguiriam continuar sem a ajuda em tempo real, 
ao vivo, do grupo de Bangalore. 

Entao, a equipe formulou um piano de ataque. Eles olharam para seus varios 
processos de suporte e suas medidas associadas, e montaram um piano para tanto 
voltar para o turno de um dia quanto para fazer melhorias significantes para seus 
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clientes, simultaneamente. Como lider de operates ativas no centra de software, 
eu os ajudei a sofisticar o piano e estive presente (como apoio moral) na proposta 
formal que eles fizeram ao chefe dos Estados Unidos. 

Eles sabiam que isso seria um assunto delicado para o chefe, que teria que res¬ 
ponder aos seus clientes americanos pessoalmente. 

Naturalmente houve muita trepida^ao entre os membros da equipe conforme 
a reuniao comeqou. Entretanto, o chefe da equipe ficou tao impressionado e feliz 
que imediatamente assinou a proposta, e a equipe pode colocar seu piano em a^ao. 
Dentro de poucas semanas, a loucura tinha acabado e todo mundo estava de volta 
para o turno do dia. 

A solidez desse piano para, nao apenas lidar com a mudan^a na carga hora- 
ria, mas tambem para as melhorias estrategicas na performance da equipe, inspi- 
rou grande confian^a em seus chefes e, eventualmente, em seus clientes. O gerente 
da equipe usou o piano quando comunicou a mudan^a a seus clientes. E a equipe 
prosseguiu assim. Dentro de meses, estavam funcionando dentro de um novo ni- 
vel de eficiencia. Desde entao eles conquistaram tanta credibilidade e confian^a que 
receberam mais e mais propriedade e independence em seus trabalhos. 

A equipe usava seu piano como uma resposta completa a um problema. Eles se 
dirigiam ao seu chefe nao com reclama^oes, mas com propostas de soluijoes. 

Seus lideres querem que voce tenha independence e propriedade. Fazer, execu- 
tar, e comunicar seus pianos ira ajuda-lo a obter ambos. 

Falhar e copiar 

por Patrick Collison 

Larry Wall escreveu que as caracteristicas de um otimo programador sao a pre- 
gui^a, a impaciencia e a arrogancia. Eu nao sei se isso e inato ou se pode ser adquirido 
com o tempo. De qualquer forma, nao e facil usar essa informa^ao para se tornar um 
programador melhor. Entao, em vez de olhar as caracteristicas, deviamos olhar para 
as atividades que vao ajudar a trazer melhorias. 

Se eu tivesse que escolher duas, diria falhar e copiar. 

Eu falho mais do que a maioria dos programadores que conhe^o. Certamente, a 
maior parte dos meus projetos falha. Dentro do meu diretorio Pro jects na minha 
maquina, eu tenho um monte de ideias interessantes negligenciadas, cada uma com a 
mesma probabilidade de dar certo quanto a de um peixe fugir do seu aquario. Assim 
como em familias, projetos bem sucedidos sao parecidos, enquanto cada projeto mal 
sucedido falha de um jeito proprio. 
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E apesar de ser quase um cliche dizer que a falencia de uma empresa da uma 
otima experiencia, eu nao oui;o a mesma ideia com rela^ao a programa^ao. 

(Eu sou bom nos dois, todavia, tive empresas que faliram tambem.) 

Falencia comercial tende a construir um tipo de experiencia bem direta. Voce 
aprende a importancia de guardar dinheiro, ou voce se torna mais determinado. Mas, 
em se tratando de programa^ao, nao e muito a experiencia de falir que e valiosa e 
que importa, mas sim o conhecimento adquirido enquanto se trabalha nos projetos 
que podem falhar. 

Quando comecei a programar, muito de meu tempo era gasto em tentativas fa- 
lhas de escrever todos os tipos de coisas incriveis: sistemas operacionais, sistemas 
de arquivos, maquinas virtuais, reimplementa^ao de protocolo de rede, interpreta- 
dores e compiladores JIT. A maioria deles nunca funcionou direito, e aqueles que 
funcionaram eram mesmo assim muito ruins. E claro, mesmo ignorando os aspec- 
tos tecnicos, a maior parte estava condenada desde o principio. Eu nao tenho certeza 
de qual fra^ao de 1% e a taxa de sucesso para se criar um novo sistema operacional, 
mas e pequena. 

Ainda assim, para mim, esses projetos sao a forma mais gostosa da programa^ao. 
Sao problemas fundamentais de engenharia de software. E tudo questao de um perde 
e ganha entre espa<;o, velocidade, confiabilidade e complexidade, sem ter um codigo 
cheio de bugs em vista. 

Esses sao os tipos de problemas nos quais voce pode ficar enfiado durante meses e 
mesmo assim nao conseguir sair com alguma coisa que funcione — como aconteceu 
comigo. 

Nao sei exatamente por que, mas as pessoas que estao aprendendo programa^ao 
hoje nao parecem muito ter esse tipo de experiencia. 

Eu acho que isso pode ser, ao menos parcialmente, devido a ascensao de siste¬ 
mas web. Poucos dias atras, uma pessoa da Hacker News perguntou se ainda existia 
alguem interessado em escrever software client-side. E um exagero, mas nao esta tao 
longe da verdade. E ei, software para web e mesmo bem legal. 

Do ponto de vista de um programador, contudo, essa mudan^a tern uma desvan- 
tagem. Apps web raramente envolvem duros desafios tecnicos, ate que voce precise 
enfrentar os problemas de compatibilidade do Internet Explorer. 

Em outras palavras, a barreira de entrada para o fracasso e maior. Voce tern que 
ser bem sucedido antes. 

Portanto, especialmente dado este movimento em dire^ao aos sistemas web, eu 
penso que e importante procurar por projetos sujeitos a falhas. 
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Capitulo 32. Diga, fa<;a, mostre 


E quanto a copiar? Para se tornar um melhor programador, qualquer pessoa lhe 
dira que voce deve ler codigos bons. Mesmo que eles presumidamente nao queiram 
dizer isso literalmente (isso seria realmente chato), “ler” permanece sendo, no fundo, 
uma ideia errada: e passivo. Em vez disso, eu acho que voce deve ativamente copiar, 
sem do e sem ter vergonha disso. 

Isso se aplica a muitas coisas, e claro. Hunter S. Thompson nao apenas lia bons 
livros; ele redigitava Hemingway e Fitzgerald. E os manuscritos mais velhos conhe- 
cidos do Bach eram transcribes que Bach fazia de trabalhos de outros organistas. 
Um dos casos mais famosos, talvez, seja o de Gates pegar programas em latas de lixo 
em Harvard. 

Nao e muito dificil entender como isso ajuda. Copiar constroi memoria muscu¬ 
lar. Voce sente a nuance e a forma do original — o tipo de detalhe que seria perdido 
em uma leitura rapida. 

No caso de codigo, tambem ha um beneficio menos obvio — mas significante. 
Copiar permite ir mais fundo com projetos que possam vir a falhar. Isso pode ser 
uma transcribe franca da, digamos, implement ab® de uma hash-table (o que tor- 
nou meu primeiro interpretador “menos pior”) ou um design que apenas inspirou e 
se moldou ao original (como, digamos, o Linux foi pelo Minix). 

Na melhor das hipoteses, isso leva a um tipo de ciclo virtuoso de falhar e copiar, 
que se torna um autoaprimoramento pregui^oso. 

Voce lida com algo duro, tropeeja em algum problema insuperavel, copia a solu- 
b° de outra pessoa e, ei, agora voce sabe o que fazer, o que quer que seja. 

Nesse roubo irrestrito, a medida que voce sinceramente absorve varias tecnicas, 
voce descobre como usa-las de uma nova maneira. Eu nao sei ao certo o que Picasso 
quis dizer com “Bons artistas copiam, enquanto otimos artistas roubam”. Talvez ele 
estava apenas sendo intencionalmente perverso, mas o significado inicial e o que eu 
sempre presumi. 

Programabo e cheia de ideias estranhas. Usar nomes mais curtos e menos des- 
critivos frequentemente produz codigo que e mais legivel no geral. As linguagens 
mais poderosas geralmente tern, de longe, menos conceitos do que as menos po- 
derosas. E falhar e copiar pode ser o melhor jeito de produzir um trabalho bem 
sucedido e original. 

Patrick Collison e um aluno do MIT 
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Capitulo 33 

Percep^oes e perssepisoes 

E confortavel bancar o idealista e fingir que voce nao liga para o que as outras pessoas 
pensam de voce. Voce nao pode se deixar acreditar nisso. Voce deve se preocupar 
com o que as outras pessoas pensam de voce. Percep^ao e realidade. Supere isso. 

Voce provavelmente conhece o cliche da velha questao filosofica, “Se uma arvore 
cai no meio da floresta mas ninguem esta la para ouvi-la cair, ela fez um som?” A 
correta resposta para isso e: “Quern se importa?” 

Quero dizer, a queda provavelmente produziu um som. Nao e uma resposta 
muito interessante em um nivel metafisico, mas ela provavelmente o fez. Mas, se 
ninguem a ouviu cair, o fato de ela ter produzido um som nao importa. 

A mesma coisa vale para seu trabalho. Se voce arrasa e ninguem esta la para ver, 
sera que voce arrasou mesmo? Quern se importa? Ninguem. 

Na subcultura burocratica de TI, na India, eu estava abismado com como eles 
realmente nao conseguiam entender essa simples verdade. Quase todo mundo com 
quern lidei la nao entendia por que devia ser importante que seus chefes, por exem- 
plo, soubessem o que ele estava fazendo. Se voce soubesse que voce estava melho- 
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rando cada vez mais, isso se refletiria nos comentarios de sua performance, em sua 
avalia^ao e em seu salario. Eles tinham se enganado ao pensar que a forma como os 
outros os viam era, de alguma forma, subserviente a verdade seja la qual fosse. 

Essa coisa da verdade... o que e isso? O que e bom e o que e ruim em um sentido 
absolute? 

A resposta e que nao ha um bom ou ruim absoluto, ao menos nao em termos 
de julgar quern e melhor em um trabalho que exige criatividade e conhecimento. 
Como voce define o que faz uma musica ser boa? E quanto a um bom quadro? Voce 
pode ter suas proprias definiijoes, mas eu duvido que eu concordaria com elas. Sao 
subjetivas. 

Avalia^oes de performance nunca sao objetivas. 


Os pessimos departamentos de recursos humanos de pessimas empresas giram 
suas engrenagens buscando modos objetivos de mensurar as pessoas que contratam. 
As vezes, eles nem implementam sistemas de avalia^ao “objetivos”. Todos os mem- 
bros da minha equipe na India achavam que eles deveriam ser medidos dessa forma. 

Nao existe maneira de medir objetivamente a qualidade de um trabalhador li- 
gado ao conhecimento, e tambem nao ha como medir objetivamente a qualidade 
de seu trabalho. Va em frente. Discorde. Agora pense em seu argumento por um 
instante. Percebe as falhas? 

Entao, se a medida de sua eficacia em sua empresa (ou industria, ou mercado de 
trabalho, o que for) e subjetiva, o que isso significa? Que voce sempre sera avaliado 
baseado na percep^ao que outra pessoa tern de voce. O potencial de ser promovido 
ou de ter um aumento no salario — mesmo a decisao de se voce deve continuar na 
folha de pagamento — depende completamente da percep^ao dos outros. 

Subjetividade, baseada em gosto pessoal, implica que voce nao pode contar que 
dois pareceres serao o mesmo. Pessoas diferentes se impressionam com diferentes 
fatores. Alguns podem gostar de uma estrutura rigida, enquanto outros preferem 
mais solta, com liberdade de cria^ao. Alguns podem preferir se comunicar via e- 
mail e outros, pessoalmente, ou por telefone. Alguns chefes podem gostar que seus 
funcionarios sejam mais agressivos, enquanto outros preferem que ajam como su- 
bordinados. Voce diz “biscoito” — eu digo “bolacha”. 

Nao se trata apenas de preferencia pessoal. As pessoas interagem com voce com 
diferentes fun^oes e relacionamentos, e constroem suas percep^oes com base nas ca- 
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racteristicas mais importantes para fazer aquele relacionamento em particular fun- 
cionar bem. Se eu sou gerente de um projeto, a qualidade de seu codigo fonte e muito 
menos importante para mim do que a qualidade de nossa comunica^ao. Se eu sou 
um colega de programa^ao, sua habilidade bruta e sua criatividade dirigem a per- 
cep^ao que tenho de voce mais que, por exemplo, seu acompanhamento. Mas se eu 
sou seu chefe, a habilidade crua e fundamentalmente insignificante para mim, a nao 
ser que voce realmente faca algo com isso. 

Nos culturalmente nos treinamos para perceber que lidar com a percepijao e, de 
certa forma, uma atividade suja e vergonhosa. Mas, como voce pode ver, controlar 
a percep^ao e apenas pratico. Quando voce explicitamente nota so fatores que diri¬ 
gem as percep^oes que outras pessoas tern de voce, voce descobre com mais firmeza 
como deixar os clientes felizes. Voce nao vai impressionar seu cliente com suas habi- 
lidades de programa^ao orientada a objeto. Voce pode ser um genio em design, mas 
se voce nao consegue se comunicar efetivamente e voce nao consegue completar seu 
trabalho a tempo, seus clientes pensarao que voce e ruim. Nao e culpa deles. Voce e 
ruim. 

Percep^oes realmente importam. Elas o mantem empregado (ou desempre- 
gado). Elas o levam a promo^ao ou o deixam preso no mesmo cargo por anos. Elas 
lhe dao aumento ou diminui^ao em seu salario. Quanto mais cedo voce se superar e 
aprender a lidar com percep^ao, mais cedo voce estara no caminho certo. 

Fa$a algo 

1) Percep^oes sao conduzidas por diferentes fatores, dependendo de qual o publico 
alvo. Sua mae nao se importa muito sobre quao bem voce consegue programar 
sistemas orientados a objetos, mas seus colegas de equipe sim. 

Entender o que e importante em cada relacionamento e uma parte crucial para 
formar percep^oes verossimeis naqueles com quern voce interage. Pense nos di¬ 
ferentes tipos de relacionamento que voce geralmente tern com as pessoas do es- 
critorio. Por exemplo, voce provavelmente tern colegas que fazem o mesmo tipo 
de service que voce. Voce tambem provavelmente tern um chefe direto, e talvez 
voce tenha um ou mais clientes e um gerente de projeto. 

Pegue esses grupos diferentes (ou quaisquer que se aplicarem, dada a estrutura 
de seu ambiente de trabalho), e os liste. Proximo a cada um, escreva quais dos 
seus atributos mais provavelmente vao conduzir a percep^ao daquele grupo sobre 
voce. Aqui esta um exemplo: 


147 



Casa do Codigo 


Grupo 


Condutores de per 



Colegas de 
equipe 

Habilidades tecnicas, sociais e 

' ■ 

Chefe 

Espirito de liderar^a, foco no cliente, habilidades de 
comunica?3o, acompanhamento, trabalho em equipe 

Clientes 

Foco no cliente, habilidades de comunica$3o, 
acompanhamento 

Gerente do 

Habilidades de comunicafSo, acompanhamento, 

projeto 

produtividade, habilidades tecnicas 


Pense um pouco sobre sua propria lista. Como voce poderia mudar seu com- 
portamento com o resultado dessa lista? De que maneira voce ja vem ajustando 
seu foco conforme interage com cada grupo? E em que sentido voce nao tern 
ajustado apropriadamente seu comportamento? 
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Capitulo 34 

Guia de aventura 


Com o risco de afirmar o obvio, o aspecto mais importante para colocar sua pala- 
vra para fora em seu ambiente de trabalho e sua habilidade de se comunicar. Ja se 
foram os dias do hacker despenteado inclinado sobre seu terminal e escrevendo co- 
digos pela luz de seu monitor nas entranhas mais profundas do servidor. O grunhido 
monossilabico ocasional nao vai funcionar. 

Mesmo que a proposta seja perturbadora, ponha-se na mente de um chefe ou 
de um cliente (eu usarei apenas a palavra diente neste capitulo para me referir a 
ambos). 

Eles sao responsaveis por algo tao gravemente importante que, em ultimo caso, 
precisam confiar em algum cara assustador de TI para a implementar algo. Eles fa- 
zem o que podem para ajudar a movimentar as coisas, mas no fim das contas eles es- 
tao a merce desses programadores. Alem disso, eles nao tern ideia de como controla- 
los ou mesmo como se comunicar inteligentemente sobre o que e que estao fazendo. 
Nessa situa^ao, qual seria o atributo mais importante que eles estariam procurando 
em um membro da equipe? Eu aposto o pre^o deste livro que nao era se eles tinham 
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memorizado os ultimos design patterns ou quantas linguagens de programa^ao eles 
sabiam. 

Eles estavamprocurandopor alguem que os deixassem confortaveis quanto aopro- 
jeto no qual estao trabalhando. 

Seus clientes tem medo de voce. 


Esses gerentes e clientes estavam conversando sobre ter um pequeno segredi- 
nho: eles tem medo de voce. E com uma boa razao. Voce e esperto. Voce fala uma 
linguagem oculta que eles nao entendem. Voce os faz sentir estupidos com seus co- 
mentarios sarcasticos (nos quais voce talvez nem teve a inten^ao de ser sarcastico). 
E seu trabalho e frequentemente o ultimo e mais importante pedagio entre a con- 
cep^ao de um projeto e seu nascimento. 

Sua fun^ao e ser o guia de aventura de seu cliente, atraves dos implacaveis ter- 
renos do mundo da tecnologia da informa^ao. Voce vai deixar seus clientes confor¬ 
taveis enquanto os guia em um lugar nao familiar. Voce os fara suspirar e os levara 
onde eles querem ir, enquanto evita as partes obscuras e decadentes que voce encon- 
trou no passado. 

Pessoas que nao programam sao, na media, tao inteligente quanto os progra- 
madores. (Isso quer dizer que a maioria deles nao e muito inteligente, mas poucos 
realmente sao). Ha grandes chances de seu cliente ser tao esperto quanto voce, mas 
nao saber como programar. Esta tudo bem. Voce provavelmente nao sabe fazer o 
que ele, por sua vez, faz em seu dia a dia. Por isso ha dois de voces, e ambos estao 
sendo pagos para aparecer no trabalho. 

Eu mencionei um pouco sobre inteligencia porque as pessoas da computa^ao, 
com muita frequencia, presumem que quern nao sabe como operar um computador 
nao e inteligente. Dizer isso tao explicitamente assim soa idiota, mas e a verdade de 
todos os preconceitos. Contudo, essa sensa^ao e tao arraigada em tantos de nos que 
nem mesmo sabemos quando a sentimos. Tentar controlar isso explicitamente nao 
funciona. 

Meu conselho e reverter o relacionamento. Em vez de se achar um genio da 
computa^ao, descendente do ceu dos computadores para salvar seu pobre cliente do 
purgatorio, vire a mesa ao contrario. Se voce esta, por exemplo, trabalhando em uma 
seguradora, pense em seus clientes como um especialista no assunto de seguros, dos 
quais voce tem o que aprender para fazer seu service. 
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Tendo dito isso, voce precisa estar ciente de que seus clientes podem precisar 
atenuar os topicos tecnicos um pouco quando voces estiverem discutindo sobre as- 
suntos relacionados a software. Ha um balance delicado entre muito tecnologo e 
muito ignorante. 

“Por que toda essa tarefa sobre como tratar seus clientes? Eu achei que nos iamos 
conversar sobre como fazer propaganda de mim mesmo.” Se voce trabalha em uma 
tipica empresa de TI, muito do or^amento que o mantem empregado vem de area de 
negocio. 

Quando estao sendo tomadas decisoes sobre promotes e staff, o melhor advo- 
gado que voce pode ter e um cliente que nao quer ficar sem voce. Do outro lado, 
imagine o impacto de um cliente que pensa que voce e condescendente. Seu cliente 
representa a necessidade do negocio, e voce e pago para fornecer o suprimento disso. 
Nao se esque<;a disso. 

Fa9a algo 

1) Olhe para si mesmo — voce e aquele programador mau humorado e ogro que 
todo mundo teme? Voce tern certeza? Eles tern medo de lhe dizer? 

Va ao seu e-mail e procure exemplos de e-mails que voce enviou a colegas de 
trabalho menos tecnicos, chefes e clientes. Conforme voce le, tente ver as coisas 
a partir do ponto de vista do destinatario. Se ja passou algum tempo desde que 
voce enviou as mensagens, voce podera se ver como um observador na terceira 
pessoa. 

Melhor ainda, mostre os e-mails para sua mae. Conte para ela que alguem com 
quern voce trabalha vai enviar as mensagens para um cliente, e pergunte a ela 
como essas mensagens fariam-na sentir. 

2) Pule a cerca — encontre uma oportunidade para serjogado em uma situa^ao em 
que voce nao e especialista e, portanto, depende daqueles que sao. 

Se voce tern dois pes esquerdos, imagine-se em um time de futebol. Se voce tern 
dois polegares esquerdos, imagine que voce e parte da Equipe Nacional de Trico. 
Como voce gostaria que seus colegas de equipe se comunicassem com voce? 
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Capitulo 35 

Eu iscrevu mto beim 


Os dias do programador ogro e monossilabico acabaram. Se as empresas querem ter 
dificuldades em se comunicar com seus programadores, eles os enviarao para um 
outro continente e em um fuso horario diferente e se comunicarao apenas via e-mail 
e telefone. 

Portanto, comunicarao e importante. Na lista de tarefas que voce tem que fazer 
para permanecer empregado, isso pode parecer meio artificial, bobo ou trivial. Tal- 
vez voce se sinta como se tivesse voltado as aulas do ensino medio. Tudo bem. Desta 
vez, voce pode realmente prestar atenrao. 

Vamos passar pela mais chata primeiro: gramatica e ortografia sao importantes. 
Voce provavelmente tem um diploma em um assunto avamjado como engenharia ou 
ciencia da computarao, e aqui estou ensinando-o a soletrar. Coragem! 

Mas, pelo menos nos Estados Unidos, temos um problema. 

De acordo com uma reportagem da Comissao Nacional de Escrita (http://www. 
writingcommission.org/report.html) , mais da metade das empresas entrevistadas 
levam em considerarao as habilidades de escrita quando estao tomando decisoes 
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tanto para contratar como para promover. 40% dos entrevistados do setor de services 
disseram que um ter^o ou menos de suas contrata^oes correspondia as habilidades 
de escrita desejadas. 

Quando voce realmente da um passo para tras e olha para o grande cenario, 
habilidades de escrita sao necessarias e estao em falta. 

Como voce sabe, a for^a de trabalho mundial esta se distribuindo globalmente. 
Conforme a tendencia continua, vai chegar uma hora — para alguns, o momento e 
agora! — quando a maior parte da comunica^ao no local de trabalho sera feita em 
forma escrita, seja por mensagem instantanea ou e-mail. 

Voce escrevera muito. Se parte tao grande do seu trabalho envolvera escrever, 
e melhor voce ser bom nisso. Mais do que nunca, as percepijoes sobre voce serao 
formadas com base em sua habilidade de escrita. Voce pode ser um otimo progra- 
mador, mas se voce nao consegue se expressar em palavras, voce nao sera tao eficaz 
em uma equipe distribuida. 

A habilidade de escrever cria tanto uma percep^ao superficial de voce, como pos- 
sibilita uma real compreensao de como sua mente funciona. Se voce nao consegue 
organizar seus pensamentos em sua lingua materna de modo que os outros consi- 
gam claramente os entender, como nos podemos esperar que voce consiga fazer isso 
em uma linguagem de programa^ao? A habilidade de formular uma ideia e guiar o 
leitor por um processo do pensamento ate uma conclusao logica nao e muito dife- 
rente da habilidade de criar um design limpo e uma implementa^ao de sistema que 
futuros mantenedores poderao entender. 

Nao se trata de ser julgado. Se voce possui membros de sua equipe em fusos 
horarios diferentes em locais distantes, escrever pode ser o unico jeito que voce tern 
de explicar como voce programou algo, ou em que seus colegas devem trabalhar. 

Voce e o que voce consegue explicar. 


Comunica^ao, especialmente por escrito, e o gargalo pelo qual todas as suas ma- 
ravilhosas ideias devem passar. Voce e o que voce consegue explicar. 

Fa$a algo 

1) Comece a manter um diario de desenvolvimento. Escreva um pouco em cada 
dia, explicando em que voce tern trabalhado, justificando suas decisoes de pro- 
grama^ao e examinando dificeis decisoes tecnicas e profissionais. Mesmo que 
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voce seja seu primeiro (ou unico — depende de voce) publico, preste aten^ao na 
qualidade de sua escrita e em sua habilidade de se expressar claramente. Ocasi- 
onalmente, releia registros antigos e os critique. Ajuste seus novos registros com 
base no que voce gostou ou desgostou nos anteriores. Nao apenas sua escrita vai 
melhorar, mas voce pode tambem usar esse diario como uma forma de fortale- 
cer seu entendimento das decisoes que voce tomou, e como um lugar ao qual se 
referir quando precisar entender como e por que voce fez tal coisa. 

2) Aprenda a digitar. Se voce ainda nao e um datilografo, fa 9 a um curso ou baixe 
algum programa para ensina-lo. E mais provavel que voce se sinta confortavel e 
natural em sua escrita se voce esta confortavel com o jeito como voce o faz. E 
claro, com todas as coisas que voce tera que escrever, voce pode ja economizar 
tempo aprendendo a digitar rapidamente. 
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Capitulo 36 

Estar presente 


Voce possui a vantagem de estar frente a frente com seus lideres e seus clientes. Nao 
desperdice a oportunidade. 

Quando eu morava em Bangalore, como diretor tecnico (CTO — Chief Techni¬ 
cal Officer ) do nosso centro de desenvolvimento de software, eu tive a desagradavel 
experiencia de relatar ao gerente sobre quem eu nao apenas desgostava (e que nao 
gostava de mim), mas quem estava nos Estados Unidos. Tmhamos conversas tensas 
no telefone, tarde da noite ou logo pela manha, que se tornavam cada vez mais frus- 
trantes por causa de ruldos de fundo ou porque a linha caia. Eu escrevia e-mails lon- 
gos e descritivos tentando ajudar a encurtar a distancia e a diferen^a de fuso horario, 
mas era apenas ignorado. E se eu reclamasse sobre ser ignorado, eu seria criticado 
por escrever e-mails longos. Parecia uma situa^ao sem saida. 

Minha empresa, na epoca, tinha um processo anual de revisao de performance, 
no qual os chefes listavam o desempenho de seus funcionarios e suas (assim chama- 
das) necessidades de desenvolvimento. No topo da minha lista de necessidades de 
desenvolvimento estava algo chamado presenca. 
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Mas presen^a, nesse contexto, e uma palavra de cunho empresarial para descre- 
ver uma caracteristica bem confusa sobre lideran^a. Trata-se da qualidade imensu- 
ravel de ter sua presen^a marcada — principalmente em situates face a face. Isso 
tambem inclui a qualidade igualmente imensuravel de levar a si mesmo como um 
lider. 

Quando eu ficava sentado conversando sobre minha revisao de performance (ao 
telefone) com minha amada chefe, eu colocava o telefone no mudo quando ela dizia 
“presen^a”. Eu nao queria que ela me ouvisse rindo. Eu ficava imaginando se ela 
podia ver a minha cara de metade careta, metade sorriso, que eu nao conseguia tirar 
do rosto pelo resto da conversa. Ambos, ela e eu, sabiamos que o problema real era 
presen^a na forma mais comum do termo: eu apenas nao estava nos Estados Unidos 
com todo mundo. 

A maioria de nos que so queria compartilhar o que pensavamos, nao gostava 
dessa chefe. Ela fez pouca coisa para impor respeito, entao isso ja era esperado. O 
padrao que apareceu foi que os unicos funcionarios que tinham um relacionamento 
realmente negativo com ela eram os que nao estavam geograficamente no mesmo 
lugar que ela. 

Aqueles em outros paises, tais como India, Hungria e a Gra Bretanha (em ordem 
decrescente) tinham relacionamentos tensos com ela, ja que estavamos nao apenas 
separados fisicamente, mas tinhamos horarios, infraestrutura, cultura e limites por 
causa do idioma. 

Parecia que, mesmo para as pessoas dos Estados Unidos que faziam tudo o que 
podiam para evitar essa chefe, a proximidade fisica e as conversas frente a frente 
ocasionais eram todo o necessario para deixa-la confortavel. E, e claro, o fenomeno 
de “o que os olhos nao veem, o cora^ao nao sente” era rapidamente validado quando 
eu colocava meus pes na India. 

Alem de apenas contar uma historia sobre uma gerente ruim, voce pode apren- 
der algo mais dessa experiencia. A proximidade fisica e uma vantagem no lugar de 
trabalho. 

Pense sobre a ultima vez que um parente ou um amigo, que nao era da area da 
computa^ao, pediu-lhe ajuda com um problema do computador. Voce tenta ajudar 
pelo telefone, e se eles nao estao entendendo, voce fica cada vez mais agitado. Se 
voce pudesse mostrar para eles... Em contraste, a comunica^ao cara a cara e in- 
crivelmente eficaz. Voce pode ouvir o outro lado mais claramente. Voce pode usar 
de expressoes visuais para se fazer entender, seja com gestos ou desenhos ou lousas. 
E todos nos expressamos implicitamente bastante conteudo em nossas expressoes 
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Capitulo 36. Estar presente 


faciais, mesmo sem perceber isso conscientemente. 

Nos nao apenas vemos mais produtividade e uma comunica^ao mais aprimorada 
por meio de interaijao cara a cara, mas tambem formamos laijos pessoais mais fir- 
mes. Leva muito mais tempo criar algo que voce chamaria de amizade se voce nunca 
encontra a pessoa frente a frente. Quinze anos atras, isso era inedito para nos. Hoje 
em dia, com a ubiquidade da internet, e menos comum do que amizades tradicionais 
cara a cara. Por muitas das mesmas razoes pelas quais trabalhamos com menos efi- 
ciencia via telefone, e-mail e chat, nos tambem somos menos eficientes em construir 
um relacionamento dessa forma. Adicione a isso o desconforto da artificialidade de 
um e-mail ou de uma conversa em chat (algo de que a proxima gera^ao provavel- 
mente nao vai se lembrar), e, na maioria dos casos, o relacionamento erguido em 
um ambiente de trabalho remoto vai permanecer estritamente centrado em cumprir 
tarefas. 

Um forte relacionamento de equipe, com comunica^ao eficaz e em banda larga, 
favorece na rapidez da entrega do software. Na maior parte dos ambientes, decisoes 
importantes sobre o projeto sao feitas pessoalmente, nos intervalos para o cafe, e 
conversas paralelas. Essas sao observances bastante obvias, e a vantagem que a pes¬ 
soa tern em participar disso tambem e bastante obvio. O que nao e tao obvio — 
especialmente para nos, geeks — e a importancia de ser visto. 

Eu nunca entrei em um banco. Eu fa^o todas as tarefas bancarias ou online ou 
em caixas eletronicos. Meus avos sao diferentes. Eles fazem tudo o que precisam 
dentro do banco, conversando com pessoas reais. Eles nem gostam de conversar 
sobre negocios por telefone. Nao e confortavel para eles. Eles tambem conhecem as 
pessoas do armazem que frequentam. Eles vao e voltam varias vezes e conversam na 
saida. Eles nao pensam em mudar de armazem (ou de banco), porque essa escolha 
e muito mais do que algo de peso pragmatico de conveniencia e custo. E pessoal. 

Enquanto nao existirem robos ou programas de computador para tratarem de 
nossas avalianoes de performance, todos os negocios continuarao sendo pessoais. 
Nos, pessoas, gostamos de interagir com outras pessoas pessoalmente. Alguns de 
nos, de qualquer maneira. 

O modo de trabalho natural de uma pessoa da computanao e se enfiar em um 
cubiculo, colocar seus fones de ouvido, e entrar “no clima” ate a hora de comer. Dou¬ 
glas Coupland, em seu livro Microserfs [1], conta a agradavel historia de uma equipe 
que tinha que comprar comidas achatadas para poder passar debaixo da porta do 
escritorio de um programador em uma missao. Esse tipo de isolamento focado se 
tornou parte da cultura e do folclore da industria de software. 
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Infelizmente para a sua carreira, isso e ruim para o mercado. Se voce esta tran- 
cado em um escritorio, acessivel apenas por telefone (se voce atender) ou e-mail, e 
talvez ate trabalhando todas as horas da madrugada e dormindo tarde, como con- 
sequencia, nao existe diferen^a entre voce estar no mesmo local que seus chefes e 
clientes, ou estar no offshore. Voce esta perdendo uma grande oportunidade de se 
tornar uma figura memoravel em sua empresa. Lembre-se, voce precisa tornar as 
coisas pessoais, e para isso, voce precisa lembrar da tendencia humana natural de 
querer trabalhar com outros seres humanos — nao por mensagem de voz, e-mail, 
ou mensagens instantaneas, mas pessoas reais. 

Aprenda sobre seus colegas. 


No atual ambiente distribuido, voce pode pensar que, embora esteja no mesmo 
pais que as pessoas com quern voce trabalha, voces nao estao no mesmo estado ou na 
mesma cidade. Viagens regulares para ter reunioes pessoalmente sao otimas nessas 
situates se isso for pratico para voce e sua empresa. Mas a melhor coisa que voce 
pode fazer e pegar o telefone e ligar para seus chefes e colegas. Nao use microfo- 
nes, e nao dependa de reunioes agendadas. Voce precisa tentar simular o tipo casual 
das conversas dos intervalos para o cafe que voce teria se morasse ou trabalhasse no 
mesmo lugar; portanto, separe um tempo para conversas (aparentemente) esponta- 
neas. Na ocasiao, espere a oportunidade de tornar a conversa pessoal. Deixe que 
o “Como vai hoje?” siga para o “O que voce geralmente faz nos finais de semana?” 
Tente aprender de verdade sobre as pessoas com quern voce trabalha. Nao apenas 
isso o firma mais em sua empresa, como tambem e uma forma mais enriquecedora 
de viver. 

Fa$a algo 

1) Na proxima semana, pegue um dia para se for<;ar (com razao) a nao mandar ne- 
nhum e-mail. Toda vez em que voce iria, normalmente, enviar um e-mail, ou 
telefone para a pessoa ou, melhor ainda, va ate o escritorio e converse com ela 
pessoalmente. 

2) Fa^a uma lista de colegas, chefes e clientes com quern voce nao conversa o sufi- 
ciente. Coloque compromissos recorrentes em sua agenda para ligar e falar com 
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eles (ou pelo telefone, ou pessoalmente). Torne as conversas curtas mas signifi- 
cantes. Use-as para falar de coisas relacionadas ao trabalho e tambem para sim- 
plesmente estabelecer um contato humano. 
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Capitulo 37 

Fale com propriedade 


Todos os meus jovens sobrinhos usam o computador regularmente. Eles sao, rela- 
tivamente falando, bons entendedores de computador. Eles se comunicam com os 
amigos pelo mundo afora. Sentem-se completamente confortaveis com mensagens 
instantaneas, e-mail, baixar coisas da internet, e, e claro, tornarem-se publicos e to- 
das as coisas que voce faria se fosse um aluno do ensino medio. 

Mas se eu fosse me exibir para eles, dizendo que meu novo computador tern um 
disco rigido de 10.000 RPM Serial ATA, eles podem, na melhor das hipoteses, tentar 
adolescentemente fingir um entusiasmo. Eles tambem ficariam pouco interessados 
se eu lhes dissesse que tenho varios gigabytes de RAM e um GPU mais rapido do 
que os CPUs nos sistemas que usei apenas cinco anos atras. 

Contudo, se eu lhes dissesse que eles podem rodar o mais novo jogo de tiros em 
primeira pessoa, em alta resolu^ao sem que a aparencia visual do jogo fique pipo- 
cando, eles se sentariam e me escutariam. 

Gigahertz e rotates por minuto nao sao interessantes para a maioria dos meni- 
nos de 14 anos. Jogos de computador, sim. 
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Pessoas de negocio nao estao tao interessados em gigahertz e RPM, tampouco. 
Eles gostam quando suas aplica^oes sao rapidas, porque nao tern que esperar en- 
quanto estao no telefone com um cliente, ou enquanto tentam fechar as contas do 
trimestre. 

Mas eles nao ligam para quantos pedidos por segundo o servidor de sua nova 
aplica^ao customizada pode atender. 

Os negocios e aqueles que lidam com ele estao interessados nos resultados. Por- 
tanto, promover suas realiza^oes em qualquer outra lingua que nao a linguagem de 
negocio e ineficaz. 

Promova suas realiza^oes na linguagem do seu negocio. 


Voce nao faria uma propaganda de um produto destinado ao publico ameri- 
cano em alemao. Uma empresa de refrigerantes nao tentaria vender uma bebida 
baseando-se na quantidade de corante n°8 que ela contem. O senso comum ensina 
que, para vender um produto para um determinado publico alvo, voce deve se di- 
rigir a essa audiencia em uma linguagem que eles podem tanto entender como se 
referirem a ela. 

Como um desenvolvedor de softwares, isso significa esbo^ar suas realiza^oes 
dentro do contexto da empresa para a qual voce trabalha. Claro que voce o fez, mas 
o que foi isso? Por que isso importava? Por que isso foi tao chamado de realiza^ao, 
e nao apenas uma perda de tempo? 

Meu palpite e que se fosse para voce pensar nas conquistas do ultimo mes, voce 
talvez nao consiga articular a resposta de por que elas eram tarefas uteis para se 
fazer. Obviamente, mandaram-lhe realiza-las, mas quais beneficios elas agregaram 
ao negocio? 

Na General Electric, ha uma lenda urbana de que o CEO original Jack Welch 
gostava de entrar em um elevador de um dos predios da GE com um funcionario 
aleatorio que tenha subido no elevador com ele. Ele se dirigia ao ja amedrontado 
subalterno com a pergunta “Em que voce esta trabalhando?”, para entao perguntar 
(e e aqui que esta a alfinetada) “Qual e o beneficio disso?” A moral da historia e que 
voce deve sempre ter um discurso de elevador pronto, so para garantir. 

O que voce diria se seu CEO lhe fizesse a mesma pergunta, do nada? Mesmo 
tendo alguns minutos para se preparar, sera que voce conseguiria explicar o beneficio 
das tarefas que voce esta realizando ou que recentemente concluiu? Voce conseguiria 
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se expressar em palavras de modo que um alto executivo totalmente nao tecnico 
pudesse nao apenas entender, mas tambem apreciar? 

Fa$a algo 

1) Fa^a uma lista de suas ultimas realiza^oes. Escreva o beneficio de negocio para 
cada uma. Se ha conquistas para as quais voce nao consegue escrever um benefi¬ 
cio, pergunte ao seu chefe ou a um conhecido confiavel como eles enquadrariam 
o beneficio. 

2) Fa^a seu discurso de elevador e decore-o. 
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Capitulo 38 

Mude o mundo 


A pior coisa que alguem de seu trabalho pode perguntar sobre voce e “O que ele/ela 
faz?” Ter de fazer essa pergunta significa que eles nao sabem o que voce ja fez. 

E triste, mas eu nao sei o que fazia a maioria das pessoas com quern trabalhei 
em uma grande empresa de TI. Simplesmente nao se pensa assim. Eles vao ao tra¬ 
balho, cumprem seus compromissos e voltam para casa. Nao ha nenhum impacto 
marcante deixado por eles, que nao seja o peda^o de codigo, documentos e e-mails 
que deixaram no historico. 

Isso e o que acontece quando voce vai trabalhar sem uma missao. Voce apenas 
fica sentado, esperando que lhe digam o que fazer. E, quando voce realiza a tarefa 
mandada, as unicas pessoas que saberao o que voce fez sao aquelas que o requisita- 
ram. Tudo bem se voce quiser trabalhar seguindo a logica de varejo ou mesmo se 
voce quiser ser um programador offshore. 

Tenha uma missao. Assegure-se de que os outros saibam disso. 
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Porem, se voce quer ser um desenvolvedor de software em um pais de alto custo, 
voce precisa ir ao trabalho com uma missao. Voce precisa fazer a mudan^a, mas nao 
mudar a si mesmo ou seu trabalho (que e dado). Voce precisa efetuar mudan^as 
visiveis atraves de sua equipe, da organiza^ao, da empresa. 

A mudan^a pode ser pequena. Voce pode ter a chave do teste de unidade, ditando 
praticas de testes para todos os programadores de sua empresa. Ou pode ser algo 
maior, com a introdu^ao radical de uma nova tecnologia, que levara a sistemas mais 
baratos e feitos mais rapido. 

Voce faz essas coisas porque voce e internamente guiado para faze-las. Voce 
nao pode se afastar e assistir as pessoas fazerem coisas erradas. Voce sabe que tudo 
poderia ser melhor, entao voce deve muda-las. 

E claro, se voce quer mudar o mundo, esta ao mesmo tempo fadado a deixar 
algumas pessoas bravas. Tudo bem, contanto que suas inten<;6es estejam certas. Nao 
seja um idiota a respeito disso, mas tambem nao precisa andar na ponta dos pes se 
fazendo de conservador sempre. 

Se voce realmente acabar eliminando algumas pessoas, podera, pelo menos, se 
sentir confortavel pelo fato de que nao vao mais perguntar “O que voce faz?” 

Se voce nao sabe qual e sua cruzada, provavelmente nao possui uma. Se ainda 
nao esta ativamente tentando deixar sua marca, voce provavelmente nao esta con- 
seguindo. 

Fa9a algo 

1) Catalogue as jornadas que voce pessoalmente testemunhou em seu ambiente de 
trabalho. Pense nas pessoas com quern voce trabalhou, que agiam como se ti- 
vessem uma missao. Pense nas pessoas mais focadas e eficazes de sua empresa. 
Quais eram suas missoes? 

Voce pode pensar em alguma delas que tenha sido inapropriada? Qual o limite 
entre foco e obsessao? Voce ja viu alguem passar desse limite? 
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Capitulo 39 

Fa<;a sua voz ser ouvida 


As ideias que exploramos ate aqui foram razoavelmente conservadoras e focadas em 
ser reconhecido pelo que voce faz em seu trabalho. Se voce quer ser percebido, pro- 
movido, ou mesmo bear empregado em sua empresa atual, os topicos nos quais to- 
camos serao criticos. 

Mas que chato! 

O mundo esta mudando. Se voce quer garantir sua passagem, e preciso pensar 
mais alto do que os trabalhadores de TI do ano passado. Enquanto progredir de um 
nivel 23 para o 24 na programa^ao possa realmente ser seu objetivo de carreira a 
curto prazo, sendo um programador hoje, voce deve pensar alem da proxima pro- 
mo^ao ou alem ate do seu emprego atual. 

Observe-se mais do alto. Nao se defina como um programador de uma empresa 
especifica — afinal, e provavel que voce nao fique no mesmo lugar para sempre — 
mas como um membro participante de uma companhia. Voce e um artesao ou um 
artista. Voce tern algo a compartilhar alem do aplicativo de relatorio de despesas que 
voce esta desenvolvendo para o departamento de recursos humanos, ou os erros que 
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voce corrigiu no sistema de testes de sua empresa. 

Empresas querem contratar especialistas. Enquanto um curriculo com uma so- 
lida lista de projetos e um bom modo de demonstrar experiencia, nada e melhor, 
em uma entrevista de emprego, do que o entrevistador ja ter ouvido falar de voce. 
E especialmente bom se eles ja ouviram falar de voce porque leram seus artigos ou 
livros, ou assistiram a uma palestra sua em um congresso. Voce nao ia querer con¬ 
tratar a pessoa que “escreveu o livro” sobre a tecnologia ou metodologia que voce 
esta tentando implantar? 

Durante o tempo em que eu era saxofonista, eu tocava bastante nos clubes perto 
da rua Memphis’s Beale. Conforme eu comecei a me entrar na area da computa^ao, 
eu percebi varias coincidencias entre o modo como voce precisa promover seu nome 
na industria musica e na computa^ao. Quando eu era um musico tentando achar 
emprego, as seguintes propriedades eram validas: 

• (Este e o mais importante) O melhor saxofonista nem sempre e contratado. 

• Com quern voce tocou e, pelo menos, um dado tao importante como quao 
bem voce toca; musicos sao bons por associacao. 

• As vezes, os melhores musicos sao deixados para tras porque todo mundo pre¬ 
sume que eles nao estarao disponiveis, porque estao muito intimidados para 
perguntar. 

• Musica funciona via efeito de rede. Se sua rede social e musical termina antes 
de alcarujar alguem, nao e provavel que voce seja requisitado para tocar com 
aquela pessoa, ate que algum intermediary fa^a a conexao. 

A industria da computa^ao e do mesmo jeito. Nao existe um sistema objetivo 
para avaliar e empregar desenvolvedores de software. Ser bom e importante, mas 
nao o leva ate o fim. Nosso meio, como o musical, e uma grande, complexa rede de 
pessoas conectadas com outras. Quanto mais ligaijoes voce tern, maiores sao suas 
chances de se conectar com o emprego perfeito ou de despontar em uma carreira. 
Limitar-se a empresa para a qual trabalha estabelece serios limites no numero de 
conexoes que voce pode formar. 

Qual a melhor maneira, senao fazer publica^oes e falar em publico, para que seu 
nome seja propagado e sua voz se fai;a ouvida? Entao, como voce deixa de ser um 
programador Ze Ninguem para ser um autor publicado e um palestrante publico? 
Comece na web. 
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Capitulo 39. Fa<;a sua voz ser ouvida 


Primeiro, leia blogs. Aprenda mais sobre a organiza^ao dos blogs e procure se 
tornar um membro. Se voce nao sabe o que ler, pense em alguns autores dos seus 
livros tecnicos favoritos e pesquise na web. Voce provavelmente descobrira que eles 
tern um blog. Assine o feed e tambem os das pessoas as quais eles linkam. Com o 
tempo, sua lista de feeds vai crescer ao passo que voce le e encontra links de outros 
blogs. 

Agora abra seu proprio blog. Ha varios services gratuitos disponlveis para se 
criar um blog. E extremamente simples. Comece escrevendo (e linkando) historias 
que voce acha interessante. Conforme escreve, voce descobrira que o universo dos 
blogs e por si so uma rede social — um microcosmo da rede de carreira que voce 
esta come^ando a construir. Seus pensamentos vao eventualmente aparecer nos fe¬ 
eds agregados e de outros que curtem suas postagens, que escreverao sobre isso e 
compartilharao suas ideias. 

O blog e um campo de treinamento. Escreva na internet como se voce estivesse 
escrevendo em uma coluna de sua revista preferida. Pratique a arte de escrever. Suas 
habilidades vao crescer, e voce vai ganhar mais confian^a. 

Seus posts tambem vao dar exemplos de trabalho que voce pode usar no proximo 
passo. Agora que voce esta escrevendo em seu proprio ambiente, voce pode tambem 
enviar seus topicos para comunidades, revistas ou ate livros. Com um portfolio de 
sua habilidade de escrita disponivel na internet, voce tera bastantes exemplos de ma¬ 
terials para incluir em um artigo ou em uma proposta de livro. Publique, e sua rede 
crescera. Quanto mais textos, voce tera mais oportunidades de escrever. E tudo isso 
leva a oportunidade de palestrar em conferences. 

Assim como nos facilmente come^amos na internet nossos empreendimentos 
de escrita, voce pode come^ar sua carreira de palestrante em seus encontros de de- 
senvolvedores locais. Se voce e alguem de .NET, prepare uma apresenta^ao para o 
grupo local de desenvolvimento da Microsoft. Se voce e um programador Linux, 
converse com o grupo de usuarios de Linux. A pratica leva a perfei^ao, no que tange 
aos discursos. Assegure-se de dedicar muita reflexao quando estiver preparando sua 
palestra. Nao seja superficial. Mesmo que voce esteja palestrando para apenas um 
pequeno grupo de pessoas em sua cidade natal, e la onde voce vive e trabalha. Um 
trabalho realmente bem feito, eventualmente vai ser recompensado. Voce desco¬ 
brira que, se voce der a quantidade certa de aten^ao, localmente, essas pequenas pa- 
lestras nao serao diferentes das conferences nos congressos das grandes industrias. 
Estas sao, obviamente, o proximo passo logico. 

Com todas essas formas de levar seu nome e sua voz para fora, a dica mais crucial 
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de todas e come^ar tao logo quanto voce achar que esta pronto. A maioria das pessoas 
se vende mais barato do que poderia. 

Voce tem algo a ensinar. Voce nunca vai se sentir 100% pronto, entao talvez voce 
deva come^ar agora. 

Faqa algo 

1) Se voce ainda nao tem um blog, crie um agora mesmo. Va a um dos varios sites 
de hospedagem gratis e monte um. 

Agora crie um arquivo de texto em seu computador. Nele, fa 9 a uma lista de pos- 
siveis topicos para seu blog. Esses serao futures artigos que voce ira escrever. Nao 
se limite a ideias epicas. Mire em ideias sobre as quais voce pode escrever em dez 
a vinte minutos. Pare quando a lista tiver dez itens (ao menos que voce esteja 
inspirado — continue). 

Salve o arquivo mas deixe-o aberto. Se voce reiniciar, abra novamente o arquivo. 
Voce tem tres semanas. Cada dia, escolha um item da lista e escreva um artigo. 
Nao pense muito sobre isso. Apenas escreva e publique. Nos artigos, coloque 
links para outros blogs com artigos relacionados. Conforme voce le a lista para 
escolher o topico do dia, sinta-se a vontade para acrescentar ideias no arquivo. 
Depois dessas tres semanas, escolha seus dois artigos favoritos e envie-os a sites 
novos moderados por usuarios, como o Digg e o Reddit. 

Se voce ainda tem ideias em sua lista, continue a escrever. 
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Construa sua marca 


Constru^ao de marca tem duas partes: realmente fazer sua marca, de modo que as 
pessoas a reconhe^am, e ter certeza de que aquela marca e associada a tra^os positi¬ 
ves. Reconhecimento e respeito. 

Hoje, quando vemos uma suastica, pensamos no Hitler e na Alemanha nazista. 
Do ponto de vista de constru^ao de marca, aquilo foi muito bom para os nazistas. 
Eles conquistaram a primeira parte de constru^ao de marca: conscientiza^ao. Mas 
qualquer um que seja mentalmente sao tem uma associate extremamente negativa 
com qualquer coisa relacionada ao holocausto. Assim, os nazistas, em ultima ana- 
lise, falharam miseravelmente na parte de fazer associates positivas. De fato, Hitler 
roubou a suastica dos hindus, cometendo o crime que todas as empresas serias lutam 
para nao cometer. Para os hindus, que reivindicam a suastica original (ou swasti), e 
um simbolo auspicioso de bem estar. Mas agora, pelo ocidente esse icone espiritual 
foi difamado. Muito reconhecimento e pouco respeito. 

No lado oposto, esta Charlie Wood. Ele e um cantor e compositor incrivel, alem 
de tocar o orgao B3 da Hammond em Memphis, Tennessee. Ele toca cinco noites por 
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semana em um clube na rua Beale. Todo mundo que o conhece ou ouviu falar dele 
sabe como ele e brilhante. Todos o admiram. Ele e o mais talentoso que voce pode 
ser em se tratando de musica R&B. 

Mas relativamente ninguem sabe quem ele e. Nenhum reconhecimento e muito 
respeito. 

O que voce quer e tanto reconhecimento quanto respeito. Seu nome e sua marca. 
Seu nome e sua marca. 


Toda esta parte do livro e sobre como conseguir ambos. Aqui mesmo neste para- 
grafo, o que voce deve entender e que a combina^ao das duas coisas e um patrimonio 
que vale a pena construir e proteger. Diferente de um grande e assustado departa- 
mento de marketing corporativo, que processa crian^as da faculdade por sites que 
se apropriam indevidamente de alguma imagem ou frase, voce nao precisa gastar 
muito tempo protegendo sua marca de outras pessoas. A for^a mais potencialmente 
destrutiva para sua marca e voce mesmo. 

Nao enfraque<;a aquilo que voce representa. Tenha cuidado com os lugares onde 
seu nome aparece. Nao realize projetos ruins ou nao envie pessimos e-mails para 
grupos grandes (nem fa<;a posts ruins no blog para que toda a internet leia). Nao seja 
um idiota. Ninguem gosta de um idiota, mesmo se eles, de alguma forma, merecem 
ser um idiota. 

O Google nunca esquece. 


Sobretudo, lembre-se de que as coisas que voce escolheu fazer e as quais se asso- 
ciou, terao um impacto duradouro no significado que seu nome tern para as pessoas. 
Agora que muitas de nossas intera^oes se dao via internet ou foruns publicos, sites 
e listas de e-mails, muitas de nossas a^oes sao de registro publico, armazenadas em 
cache, indexadas e pesquisaveis — para sempre. 

Voce pode esquecer, mas o Google nao. 

Proteja sua marca com toda sua for^a. Defenda-a de si mesmo. E tudo que voce 
tern. 
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Capitulo 40. Construa sua marca 


Fa$a algo 

1) Pesquise seu nome no Google — digite seu nome no Google entre aspas. Veja as 
primeiras quatro paginas de resultados (sao realmente quatro paginas de resul- 
tados?). O que alguem poderia deduzir de voce depois de seguir apenas os links 
dessas quatro paginas? Voce esta bem representado nelas? Essa imagem que essas 
paginas constroem lhe agrada? 

Fai;a a mesma pesquisa de novo, mas desta vez preste aten^ao a conversas de fo- 
runs e listas de e-mails. Voce e um idiota? 
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Lance seu codigo 


Imagine como seria mais facil arranjar um emprego se houvesse empresas que ja se 
utilizassem de um software que voce escreveu. Voce poderia dizer “Oh, voces estao 
usando Nifty ++?” Eu posso ajuda-los — fui eu que inventei”. Isso seria diferente. 
Entrevistadores e gerentes de contrata^ao se lembrariam de voce. E isso que voce 
quer. 

Apenas uma decada atras, isso parecia uma boa ideia, mas nao havia muitas 
oportunidades para se fazer isso. Voce tinha que ter trabalhado para um fornece- 
dor de software comercial primeiro, e suas credenciais seriam relacionadas aos pro- 
dutos que voce ajudou a desenvolver enquanto trabalhava para eles. Mas as coisas 
mudaram. Voce nao tern mais que trabalhar para Os Grandes para desenvolver um 
software popular, com marca propria. 

Agora ha uma outra saida: open source. Software open source atingiu o mains¬ 
tream. Conforme empresas de TI come^am novos projetos, o velho debate mudou 
de construir vs. comprar para construir vs. comprar vs. baixar. Senao aplica^oes in- 
teiras, frameworks variando de pequenas bibliotecas a containers de aplica^oes estao 
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sendo lan^ados sob licen^a open source e estao, de fato, se tornando padroes. 

E as pessoas que estao desenvolvendo este software, na maior parte, sao pessoas 
como voce. Sao pessoas sentadas em suas casas de tarde e aos fins de semana, labu- 
tando em softwares como um trabalho apaixonado. E claro, existem alguns recursos 
vindos de empresas para criar e dar suporte aos produtos open source. Mas a maioria 
dos desenvolvimentos open source e feita por programadores independentes, como 
um hobby. 

Qualquer um pode usar Rails. Poucos podem se dizer contribuinte do Rails. 


Embora muitos desses desenvolvedores estejam apenas se divertindo e se expres- 
sando, ha alguns incentivos reais ai. Eles estao subindo na cadeia social de uma co- 
munidade. Estao construindo nome para si mesmos. Estao construindo uma repu- 
ta^ao na industria. Eles talveznao o estejam fazendo de proposito, mas estao fazendo 
marketing de si proprios no processo. 

Alem de construir um nome para si mesmo, contribuir com software open source 
mostra que voce e apaixonado pela sua area. Mesmo se uma empresa nao usou ou 
ouviu falar de seu software, o fato de voce te-lo criado e lan^ado ja e um diferencial. 
Pense desta forma: se voce estivesse querendo contratar um desenvolvedor, voce 
preferiria alguem que se dedica apenas em suas horas de trabalho e depois vai para 
casa e assiste a TV? Ou voce iria preferir alguem que tern tanta paixao pelo que faz 
que se supera e ate faz horas extras programando em finais de semana? 

Contributes open source demonstram habilidade. Se voce esta produzindo 
codigo real e contribuindo para um projeto real, isso e muito melhor em seu curri- 
culo do que apenas dizer que voce conhece a tecnologia. Qualquer um pode escre- 
ver Rails ou Nant em seu curriculo. Muitos poucos podem escrever contribuinte do 
Rails ou commiter do Nant. 

Liderar um projeto open source pode demonstrar muito mais do que competen¬ 
ce tecnica. Sao necessarias habilidades em lideran^a, gerenciamento de releases, do- 
cumenta^ao, e suporte a produtos e comunidades para promover uma comunidade 
em torno de seus esfor^os. E se voce fizer essas coisas com sucesso — em seu tempo 
livre, como um hobby — voce sera incrivelmente diferente da maioria de pessoas 
competindo pelos mesmos cargos. A maior parte das empresas nao pode pagar seus 
programadores para fazer todas essas coisas e bem feitas. A maioria nao consegue 
nem pagar seus desenvolvedores para fazer algumas dessas coisas bem. Mostrar que 
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voce nao apenas pode faze-las, mas que voce se preocupa o suficiente para faze-las 
gratuitamente, demonstra um surpreendente poder de iniciativa. 

Se voce cria algo realmente util, voce pode ate terminar famoso. Voce pode ser fa- 
moso em um pequeno campo tecnico — talvez famoso entre desenvolvedores Rails, 
por exemplo. Ou, se voce tiver sorte, poderia ser realmente famoso mesmo fora da 
comunidade geek como Linus Torvalds ou... bem, como Linus. Mesmo se voce nao 
e tao famoso, lan^ar seu codigo vai, definitivamente, torna-lo mais famoso. Se fama 
significa que muitas pessoas sabem quern voce e, entao ter mais uma pessoa que 
saiba de voce o torna mais famoso. E a comunidade open source e uma rede mun- 
dial de pessoas que, pesquisando codigos na internet, podem encontrar seu software, 
instala-lo e usa-lo. Ao fazer isso, eles o conhecerao, e, conforme seu software se es- 
palha, seu nome e sua reputa^ao tambem crescerao. E disso que se trata o marketing. 
£ o que voce quer. 

Fa£a algo 

1) Stuart Halloway (http://thinkrelevance.com) tern um workshop feito em congres- 
sos que chama de “Refactotum”. Se voce tiver a chance de participar, eu realmente 
o recomendo, mas a essencia e o seguinte: 

Pegue uma parte de um software open source com testes de unidade. Rode os 
testes por um analisador de cobertura de codigo. Encontre a parte menos testada 
do sistema e escreva testes para melhorar a cobertura daquele codigo. Codigos 
nao testados geralmente sao codigos nao testaveis. Refatore para torna-lo mais 
testavel. Envie um patch com a sua altera^ao. 

O legal e que isso e mensuravel e pode ser feito rapidamente. Nao ha desculpas 
para nao tentar. 
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Seja marcante 


O curriculo tradicional de marketing se refere aos quatro P: produto, pre^o, promo- 
i;ao e pra^a ( product, price, promotion and placement). A ideia e que, se voce cobrir 
todas essas quatro categorias, voce tera um piano de marketing completo, sendo que 
as quatro recebem o mesmo peso. 

Mas qual o objetivo do marketing? Seu proposito e criar conexao entre os pro- 
dutores e consumidores de um produto ou um servi^o. Esta liga^ao come^a com a 
consciencia sobre um produto. O mecanismo tradicional de criar consciencia e via 
promotes, incluindo propagandas, postagens, e seminarios educacionais. 

Recentemente, o mundo do marketing tern voltado sua aten^ao para o que e co- 
loquialmente chamado de marketing viral. Isso acontece quando a ideia e marcante 
o suficiente para os consumidores a espalharem uns aos outros. Ela propaga como 
um virus, sendo que cada consumidor infectado potencialmente pode infectar mui- 
tos outros. 

Marketing viral nao e preferido apenas porque e caro enviar postagens ou com- 
prar um tempo de propaganda na televisao. Sim, porque os consumidores confiam 
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mais em seus amigos do que em um comercial da TV ou um spam. Eles sao mais 
propensos a comprar algo sobre o que ouviram falar de seus colegas de trabalho do 
que algo que viram em um anuncio no meio do jornal de domingo. 

Em seu livro Purple Cow [4] o mestre em marketing Seth Godin faz a obvia ana- 
lise de que a melhor maneira de fazer um consumidor notar um produto e faze-lo 
marcante. Godin vai mais longe e afirma que os quatro P sao obsoletos, e que os 
consumidores se tornaram entorpecidos por essa estrategia de marketing em massa. 
A linica maneira de se destacar em uma multidao, na verdade, e ser brilhante. 

Entao, aqui e onde os leitores cinicos come^am a aplaudir. Todo o falatorio de 
marketing que voce pode fazer nao e nada comparado ao poder de um conjunto de 
capacidades marcantes. Antes de voce comeijar a dizer “Eu te disse”, nos provavel- 
mente deviamos conversar sobre a defini^ao de marcante. 

Marcante definitivamente nao significa o mesmo que “bom”. Geralmente, pro- 
dutos que sao marcantes sao bons. Mas produtos que sao bons sao raramente mar¬ 
cantes. Ser marcante significa que algo merece sua atemjao. Voce nao vai se tornar 
um marcante desenvolvedor de software simplesmente por ser melhor do que outros 
programadores que voce conhece. 

Ser melhor do que alguem nao e algo suficiente para resultar no aumento da sua 
reputa^ao. Se alguem perguntar, pode ser que voce tenha um conjunto de indicates 
brilhante, mas ser marcante significaria que as pessoas conversaram sobre voce antes 
que lhes perguntassem. 

Para ser marcante, voce deve ser significativamente diferente daqueles ao seu re- 
dor. Muitas das estrategias de marketing pessoal discutidas nesse capitulo sao mon- 
tadas focadas na notoriedade. 

Lam;ar softwares open source bem sucedidos, escrever livros e artigos, e dar pa- 
lestras em conferences podem contribuir para aumentar sua notoriedade. 

JFafa demonstrates ou morra! 


Se voce reler o ultimo paragrafo, embora nao seja uma lista exaustiva, voce notara 
que cada um dos itens que eu inclui como sendo potencialmente marcante envolve 
fazer algo. Voce pode ser o mais esperto ou o mais rapido, mas apenas ser nao e 
bom o suficiente. Voce precisa estar fazendo. 

Godin usa a expressao vaca roxa (purple cow) para nos lembrar do que e neces- 
sario para ser marcante. Nao e a melhor vaca, ou a vaca mais leiteira, ou a vaca 


182 



Casa do Codigo 


Capitulo 42. Seja marcante 


mais bonita. Uma vaca roxa iria se destacar em um meio de vacas melhores, mais 
leiteiras e mais bonitas. Seria sobre a vaca roxa que voce falaria depois de ver esse 
grupo. 

O que voce poderia fazer que tornaria a si mesmo e suas realiza^oes como a 
vaca roxa? Nao apenas seja mestre em um assunto — escreva um livro sobre isso. 
Escreva geradores de codigo que tornem o que costumava ser um processo de uma 
semana para um de cinco minutos. Em vez de ser respeitado entre seus colegas de 
trabalho, torne-se a autoridade mais reconhecida de sua cidade no que diz respeito a 
tecnologia na qual voce se foca. Fa^a algo previamente impensavel em seu proximo 
projeto. 

Nao deixe que voce seja apenas o melhor em um grupo. Seja o cara e fa^a coisas 
sobre as quais as pessoas nao podem deixar de falar. 

Fa£a algo 

1) Comece pequeno, mas tente fazer algo marcante em seu atual projeto ou traba¬ 
lho. Uma das maneiras de experimentar isso e tentar alcan^ar uma produtividade 
marcante. Agendas de projeto normalmente sao sobrecarregadas. Encontre algo 
que todos pensam que precisara de uma semana para ser feito e fa<;a em um dia. 
Trabalhe horas extras para isso se voce achar necessario. Voce nao precisa fazer 
disso um habito, mas sim, levar isso como um experimento. Fa^a o trabalho em 
um periodo de tempo marcante. Veja se as pessoas “notam”. Se nao, por que nao? 
Se sim, de que forma? Aline as variaveis e tente de novo. 
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Capitulo 43 

Fazendo o gancho 


Quando eu era um jovem saxofonista no Arkansas, as pessoas me perguntavam “Oh, 
voce conhece o Chris?” — eu nao o conhecia. Aparentemente, ele era o outro ado- 
lescente na cidade que era um serio aspirante a musico de jazz. Entao, quando as 
pessoas me viam, eles faziam a obvia conexao, esperando que fossemos camaradas 
em nossa caminhada jazzistica colegial. 

No verao, eu tive a oportunidade de ver a Count Basie Jazz Orchestra tocar em 
um show ao ar livre em um anfiteatro nas margens do rio Arkansas. Com uma com- 
bina^ao de bom humor e uma coragem descomunal, acabei conseguindo conversar 
com os musicos no backstage, antes do show. Eu nunca fui uma pessoa muito con- 
versadora, entao isso foi realmente uma vitoria. Eu fiquei nos fundos conversando 
com um dos saxofonistas da orquestra, quando outra jovem criancja chegou e come- 
90U a conversar. Depois de cinco ou dez minutos, a banda come^ou, deixando-nos 
desacompanhados. “Voce e o Chris/Chad?” — nos dissemos simultaneamente. 

Nos anos que vieram, eu passei bastante tempo com Chris. Ele, eu logo aprendi, 
tinha uma estranha aptidao para se associar aos melhores musicos da cidade. Ele era 
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apenas um menino da escola. Porem, ele ja fazia shows, como substitute do pianista 
de jazz mais respeitado do Little Rock. Chris era muito bom — especialmente para 
sua idade — mas ele nao era tao bom. 

Nao me levou muito para entender o que estava acontecendo. Nos saiamos, va- 
rias vezes por semana, a clubes onde se tocava jazz. Sempre era, de alguma forma, 
uma experiencia desconfortavel para alguem introvertido como eu, mas, cronome- 
tradamente, quando a banda fazia um intervalo, Chris interrompia o assunto e me 
deixava para conversar com os musicos. Ele era como um robo. Eu preciso admitir, 
era um pouco enjoativo assisti-lo. Era tao previslvel. Ele nao estava incomodando 
os pobres musicos? Eles estavam fazendo um intervalo, pelo amor de Deus. Eles nao 
queriam conversar com essa crian^a! Tendo sido deixado de lado, ou eu tinha que 
segui-lo ou bear sentado sozinho esperando. Ocasionalmente, quando eu nao tinha 
muita energia, escolhia o segundo. Entretanto, na maioria das vezes eu o seguia e 
tentava fingir que me encaixava. 

Frequentemente, ate demais para a minha surpresa, os musicos pareciam gostar 
de conversar com Chris — e mesmo comigo. Ele era muito intrometido e sempre 
ficava pedindo para se sentar com a banda, por mais inapropriado que me parecesse. 
Ele tambem pedia aos musicos por aulas, o que significa que ele ia a suas casas para 
ouvir musica e conversar sobre jazz. Algumas vezes eu era arrastado junto, com a 
mesma sensa^ao que eu tinha nos intervalos dos shows — que eu estava incomo¬ 
dando. 

Mas obviamente era eu que estava confuso com o relacionamento que Chris es¬ 
tava desenvolvendo com aqueles musicos. Ele estava tornando o sonho real, tocando 
com musicos realmente bons. Foi ele quern me conduziu aos melhores musicos da 
cidade. Sendo que a unica diferen^a entre nos era que ele era extrovertido. 

Com o passar dos anos, sua estrategia de “ser o pior”, aliada a habilidade de desca- 
radamente se forijar para os outros, fez com que ele se tornasse um incrlvel pianista. 
De fato, ele achou sua fresta para tocar com musicos de jazz realmente famosos. Eu, 
por outro lado, ainda era o mesmo cara que ele conheceu. Ele me empurrou para al- 
guns desses shows de perfil “mais elevado”, mas era sempre ele que dava o empurrao 
— nunca o inverso. 

Desde entao, tenho visto o mesmo padrao nas pessoas que conheci em musica 
classica, na Comunidade Americana de Budismo Tibetano, desenvolvimento de soft¬ 
ware, e mesmo nos confins de um simples escritorio. Chris chamava isso de “fazer 
o gancho”, o que o tornava ainda mais repulsivo para mim. Mas o resumo da histo- 
ria e este: as pessoas realmente boas nao se incomodam se voce quiser conhece-las. 
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As pessoas gostam de ser apreciadas e gostam de conversar sobre os assuntos pelos 
quais sao apaixonados. O fato de elas serem o profissional, ou o guru, ou o lider, ou 
o autor renomado nao muda o fato de que sao humanos e gostam de interagir com 
outros humanos. 

O medo nos separa dos profissionais. 


Falando por mim mesmo (e extrapolando a partir dal), a barreira mais seria entre 
nos, mortals, e as pessoas que admiramos e nosso proprio medo. Associar-se a pes¬ 
soas espertas e bem conectadas, que podem ensinar-lhe coisas ou achar um trabalho 
para voce, e possivelmente a melhor forma de se melhorar, mas muito de nos tern 
medo de tentar. Fazer parte de uma comunidade profissional coesa e bem integrada 
e como musicos, artistas e outras pessoas da arte se tornaram fortes e evolulram por 
anos. Os gurus sao os pontos de partida nas redes sociais e profissionais. Tudo o que 
e preciso para estabelecer a conexao e um pouco menos de humildade. 

E claro que voce nao precisa come^ar a conversar aleatoriamente. Obviamente 
voce quer procurar aqueles com quem voce tern algo em comum. Talvez voce leia 
um artigo que o influenciou bastante. Voce pode mostrar ao autor o trabalho que 
voce fez como resultado, e pedir feedback. Ou talvez voce possa criar uma interface 
de software para um sistema que alguem criou. Este e um otimo e legitimo jeito de 
estabelecer a conexao. 

Obviamente, voce pode fazer isso tanto on-line como pessoalmente. Uma cone¬ 
xao duradoura e uma conexao duradoura. Os herois do mundo do software estao 
espalhados pelo mundo. O mesmo vale para a industria musical, embora voce nao 
possa confiar que todos os musicos sejam conectaveis por e-mail. Entao, o mundo da 
musica tende a formar aglomerados profissionais locais, enquanto os desenvolvedo- 
res de software tern a vantagem de serem facilmente alcan^aveis, onde quer que voce 
esteja. Isso torna facil nao apenas encontrar os gurus de sua cidade, como tambem 
qualquer guru. Algumas das mentes mais influentes do desenvolvimento de software 
estao prontamente acessiveis por e-mail e, ate mesmo, por chat em tempo real. 

A historia que me fez escrever este livro, na verdade, comeqiu com um e-mail 
sobre uma biblioteca Ruby para um de seus editores, seguido de muitas conversas via 
chat on-line. Embora eu estava timido ao mandar o e-mail inicial, aparentemente 
isso nao irritou Dave, e aqui esta voce, lendo minhas palavras. Obrigado, Chris. 
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Nao podemos simplesmente...? 

por Stephen Akers 

Qualquer pessoa que ja passou bastante tempo em seu trabalho sabe que existe 
uma luta entre tecnologia de informa^ao (TI) e o negocio (aqueles que nao sao TI). 
A raiz deste conflito e quase sempre um mal-entendido, falha de comunica^ao e ex- 
pectativas mal gerenciadas. Esses assuntos sao sublinhados quase diariamente por 
varias frases usadas por ambos os lados. 

Para TI, dentre as expressoes mais odiadas estao: “Nao podemos simples¬ 
mente...?” Geralmente ocorre algo como: Nao podemos simplesmente terceirizar 
este service? Nao podemos simplesmente colocar mais desenvolvedores no projeto? 
Nao podemos simplesmente fazer o que fizemos da ultima vez? Nao podemos sim¬ 
plesmente tornar a aplica^ao mais rapida? Nao podemos simplesmente criar um 
novo banco de dados? 

O problema e que muitas das pessoas de TI, quando ouvem essa frase, se focam 
na palavra “simplesmente”. Isso os faz sentir como se as pessoas de negocio conside- 
rassem suas sugestoes como obvias, triviais, e facilmente alcan^aveis. Qualquer falha 
na implementa^ao iria, por conseguinte, indicar que aqueles de TI foram incapazes 
de completar a mais simples das tarefas e deviam ser substituidos. 

Como resultado, uma resposta comum a esses pedidos e frequentemente “nao”. 
As pessoas de TI querem se assegurar de que as de negocio percebam que suas pro- 
postas nao sao apenas complexas e dificeis de executar, como sao, de fato, uma ideia 
ruim. Eis o conflito. Em ultima analise, o que acontece e que as pessoas de negocio 
se distanciam, com a impressao de que TI sempre diz “nao”, enquanto as de TI ficam 
com a ideia de que as pessoas de negocio nao sabem o que esta sendo feito. 

Isso e exatamente o que eu costumava pensar. Na minha opiniao, o que o nego¬ 
cio realmente precisava era de alguem em sua equipe que sabia o que eles estavam 
fazendo. Este e o motivo pelo qual, em algum momento de minha carreira, eu re- 
solvi deixar TI e partir para os negocios. Eu realmente esperava que todos os meus 
projetos tivessem grande sucesso porque eu sabia como fazer as coisas do jeito certo. 

E engra^ado como nossos pianos nem sempre resultam naquilo que esperava- 
mos. Embora eu tenha alcan^ado sucesso na equipe de negocios, nao era assim que 
eu queria marcar este ponto. 

Ao contrario disso, eu descobri que ainda havia muito o que aprender. Por exem- 

plo: 

1) Existem fatores comerciais reais que agem como limitadores em praticamente 
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todos os projetos. Essas limita^oes vao, as vezes, requerer que voce implemente 
nao menos que a solu^ao tecnica perfeita. 

2) Timelines propostas pelas pessoas de negocio geralmente nao sao tao arbitrarias 
quanto parecem. Em muitas vezes, o prazo de entrega de uma solu^ao pode ter 
um efeito cascata no projeto ou mesmo na performance da empresa. 

Uma vez que eu aprendi essas li^oes, eu percebi que as pessoas de TI tern focado 
na parte errada da expressao “Nao podemos simplesmente...” A palavra implicita 
operante nessa senten^a, na verdade, e o sujeito nos. Esta palavra implica que o 
negocio esta considerando a area de TI como uma parte critica de sua equipe. Estao 
procurando o setor de TI por ajuda para formular uma solu^ao que resultaria em 
sucesso para toda a empresa. 

Portanto, a proxima vez que voce ouvir essa frase, tente combater a resposta au- 
tomatica “nao”. Mantenha o foco na palavra “nos” e diga, com confiancja, “sim, nos 
podemos colocar mais programadores no projeto, mas isso nao seria uma boa ideia, 
porque...” Mas nao pare por ai. Nao e suficiente apenas explicar seu posicionamento. 
E preciso mergulhar mais fundo para descobrir sob quais limites comerciais o ne¬ 
gocio esta operando. Com o tempo, isso lhe dara conhecimento sobre o dominio de 
negocio e oferecera um melhor ponto de vista sobre os problemas que precisam ser 
resolvidos. A combina^ao disso com seu conhecimento tecnico o fara progredir de 
alguem que sempre diz “nao” para um parceiro sem o qual o negocio nao poderia 
sobreviver. 

Stephen Akers e vice-presidente de TI na Genscape, Inc. [/box] 

Fa£a algo 

1) Escolha um de seus softwares favoritos e mande um e-mail para seu criador. Co- 
mece agradecendo-o pelo software. Entao, fai;a uma sugestao, uma pergunta, ou 
fa^a outra tentativa de estabelecer um vinculo humano com ele. Solicite resposta. 
Se o software e gratuito ou open source, ofere^a-se para ajudar de alguma forma. 

2) Pense em algum local para voce, quern voce admire ou de quern gostaria de apren- 
der algo. Procure uma situa^ao em que voce possa encontrar essa pessoa (uma 
reuniao de um grupo de usuarios ou palestras sao otimas oportunidades), e de 
um jeito de come^ar uma conversa, mesmo se isso o deixar desconfortavel — 
especialmente se voce estiver desconfortavel. 
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Muitos de nos somos guiados pela a industria de TI porque as coisas estao sempre 
mudando. E um ambiente de trabalho fresco e excitante. Sempre ha algo novo a 
aprender. Por outro lado, contudo, esta o desanimador fato de que nossos investi- 
mentos duramente conquistados no meio tecnologico depreciam-se mais rapido do 
que um carro novo. A novidade de hoje e a tranqueira obsoleta de amanha com vida 
litil limitada. 

Suas brilhantes novas habilidades ja sao obsoletas. 


Em Leading the Revolution [5] , Gary Hamel fala sobre como os lideres incumben- 
tes de qualquer industria se tornam complacentes e, com isso, desenvolvem pontos 
cegos. Quanto mais bem sucedido for seu negocio, e mais provavel que voce fique 
confortavel com seu modelo de negocio, tornando-se incrivelmente vulneravel para 
aqueles que vem atras de voce com uma nova ideia radical — mesmo que seja es- 
tupida — que pode fazer com que seu maravilhoso e vitorioso modelo de negocio 
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pare^a um sueter desgastado e velho largado em uma discoteca. O mesmo pode ser 
dito sobre escolhas de tecnologia. Se voce domina a grande tecnologia do momento, 
como Java EE ou .NET, ate o momento de publica^ao deste livro, talvez voce esteja se 
sentindo extremamente confortavel. E um lugar lucrativo, certo? Cada site de vagas 
de emprego, ou cada se^ao de classificados no jornal, serve como uma afirma^ao em 
sua decisao. 

Cuidado. Sucesso gera arrogancia, que gera complacencia. Uma onda como J2EE 
pode dar a impressao de que nunca vai acabar. Contudo, todas as ondas ou se dissi- 
pam, ou encontram a costa eventualmente. Muito conforto por muito tempo pode 
deixa-lo indefeso, imaginando o que voce faria em um mundo sem J2EE. 

Dito isso, as pessoas tern anunciado a morte de COBOL por decadas. Cada novo 
incumbente e chamado de “o COBOL do seculo 21”, ou alguma varia^ao disso. Nos 
dias de hoje, esse rotulo e aplicado a Java. Embora eu deteste encostar, ver, ou estar 
perto de codigo COBOL, chamar Java de COBOL do seculo 21 e um grande elogio. 
Mesmo que alguns de nos adorariamos ve-lo sumir, COBOL esta aqui, e tern operado 
por um longo tempo. Programadores COBOL tern trabalhado com essa linguagem 
durante suas carreiras inteiras. Isso realmente diz algo na montanha russa da indus- 
tria. E dificil dizer se o mesmo tipo de investimento funcionaria na economia de 
hoje. 

A historia do COBOL e uma exce^ao — nao a regra. Poucas tecnologias forne- 
cem plataforma para emprego tao duradoura. A mensagem aqui nao e que voce viva 
apenas com seu conhecimento em uma tecnologia mainstream. Isso seria irrespon- 
savel. Eu vou dizer que quanto mais mainstream for seu conhecimento, maior risco 
voce tera de ser deixado na tecnologia da idade da pedra. 

Todos nos ja ouvimos as extrapolates da lei de Moore, que diz que o poder de 
processamento duplica a cada 18 meses. Se os numeros estao corretos ou nao, e facil 
perceber que a tecnologia ainda esta avan^ando com a mesma proporijao do que fazia 
em 1965, quando Gordon Moore, da Intel, fez essa asserijao. E com esses avan^os no 
poder do hardware vem os possiveis progressos do que fazer com softwares. 

O poder de processamento duplica. Com a tecnologia progredindo tao rapida- 
mente, ha muita coisa acontecendo para qualquer pessoa acompanhar. Mesmo que 
suas habilidades sejam completamente atuais, se voce nao esta praticamente no pro- 
cesso de aprender a Proxima Grande Coisa, e quase tarde demais. Voce pode estar a 
frente da curva na onda atual e atras da proxima. Timing se torna muito importante 
em um ambiente como este. 
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Capitulo 44. Ja obsoleto 


Voce deve come^ar a perceber que, mesmo se voce esta na crista da onda atual, 
voce provavelmente ja esta atras da proxima. Se timing e tudo, comece a pensar 
a frente com seus estudos. O que vai ser possivel em dois anos, que ainda nao e 
agora? E se um espa^o de disco fosse tao barato que fosse praticamente gratuito? E 
se os processadores fossem duas vezes mais rapidos? O que nao precisariamos nos 
preocupar em otimizar? Como esses avamjos mudam o que vai estourar no futuro? 

Sim, e uma aposta. Porem, e um jogo que voce vai definitivamente perder se nao 
jogar. O pior dos casos e se voce aprendeu algo enriquecedor que nao e diretamente 
aplicavel em seu emprego em dois anos. Entao ainda e melhor se voce estiver olhando 
adiante e apostando nisso. O melhor caso e se voce se mantiver a frente da curva e 
puder continuar a ser um expert em tecnologias de ponta. 

Olhar adiante e ser explicito sobre o desenvolvimento de suas habilidades pode 
fazer a diferen^a entre ser cego ou visionario. 

Fa$a algo 

1) Separe um momento semanal para investigar o que vira como vanguarda. En- 
contre pelo menos duas horas por semana para pesquisar tecnologias e come^ar 
a desenvolver suas habilidades nelas. Ponha a mao na massa com essas novas 
tecnologias. Construa aplica^oes simples. Fa^a prototipos com a nova tecnologia 
nos trechos dificeis de seus projetos que usam a tecnologia atual para entender 
quais sao as diferen^as e o que as novas tecnologias permitem. 

Coloque isso na sua agenda. Nao deixe de fazer. 
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Capitulo 45 

Voce ja perdeu seu emprego 


O emprego para o qual voce foi contratado ja nao existe mais. Voce pode ainda estar 
pensando em um salario. Voce pode ainda estar agregando valor. Voce pode ainda 
estar deixando seu chefe extasiado e feliz. Mas voce ja perdeu seu emprego. 

A coisa mais certa e que tudo esta mudando. A economia esta em constante 
movimento. Empregos se tornam offshore ou onshore. Os negocios estao tentando 
se adaptar. As coisas nao alcan^aram um ponto estavel em nossa industria. Ela esta 
como um adolescente estranho passando pela puberdade. Estranho, feio, e diferente 
ano apos ano — dia apos dia. 

Portanto, se voce foi contratado para ser um programador, nao pense em si 
mesmo como um programador. Pense em si mesmo como talvez nao mais um pro¬ 
gramador. Continue executando suas fun^oes, mas nao fique muito confortavel. Nao 
tente se acomodar com a identidade de um programador. Ou um designer. Ou um 
testador. 

De fato, nao e mais seguro (como se antes fosse) identificar-se muito proxima- 
mente com o emprego para o qual foi contratado. Se as coisas ao seu redor estao 
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mudando, e o contexto no qual trabalha esta em constante movimento, agarrar-se 
a sua fun^ao cria uma dissonancia nao saudavel que contamina seu trabalho. Voce 
pode se pegar querendo ser um programador, mas fazendo o trabalho de um gerente 
de projetos. E fazendo isso mal. 

Voce nao e seu emprego. 


De volta a antes de perder seu emprego, voce pode ter tido pianos. Voce pode 
ter imaginado seu progresso atraves dos ranks de sua empresa. Voce cumpria suas 
horas como um designer e assumia o papel de arquiteto quando a recompensa era 
devida. Voce podia ver a progressao inteira de um arquiteto ate um analista, ate lider 
de equipe, atraves da cadeia de gestao. 

Porem, voce ja perdeu seu emprego, e seus pianos mudaram. Eles vao continuar 
mudando. A cada dia. E bom ter ambi^oes, mas nao se dedique cegamente a um 
futuro longo e imaginario. Voce nao pode se dar ao luxo de ter uma visao de tunel, 
onde so se ve algo tao distante no futuro. Se voce busca atingir algum alvo em mo¬ 
vimento, voce nao mira propriamente no alvo. Voce mira no lugar ao qual o alvo 
deve ir. O caminho daqui ate la nao e mais uma linha reta. E um arco, na melhor das 
hipoteses, mas e mais provavel que seja um rabisco amorfico. 

Fa$a algo 

1) Se voce e um programador, tente por um dia ou dois fazer seu trabalho como se 
voce fosse um testador ou um gerente de projeto. Quais sao os varios papeis que 
voce poderia ter dia apos dia, que voce nunca explicitamente considerou? Fa^a 
uma lista e tente experimenta-los. Passe um dia em cada. Talvez voce nem mude 
os resultados do seu projeto, mas voce vera seu trabalho de um jeito diferente. 
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Capitulo 46 

Caminhe sem destino 


Um dos maiores problemas da America e que ela e uma sociedade guiada por metas. 
Somos uma na^ao de pessoas que sempre estao focadas no resultado de um processo, 
seja o processo de aprendizado, a carreira de alguem, ou mesmo dirigindo com seu 
carro. Somos tao focados no resultado que esquecemos de olhar para o cenario como 
um todo. 

Se voce pensar sobre isso, o foco no resultado e logicamente o inverso daquilo 
com que nos deveriamos estar perdendo nosso tempo. Voce tipicamente passa todo 
seu tempo fazendo coisas, e pouco tempo realmente atingindo metas. Por exemplo, 
quando voce esta desenvolvendo software, o processo durante o desenvolvimento e 
onde voce passa todo seu tempo, e nao no final do projeto, quando tudo esta pronto. 

Isso tambem e valido para sua carreira. O alimento real de sua carreira nao sao 
promotes e aumentos de salario. E o tempo que voce gasta trabalhando em dire- 
<;ao a esses avan^os. Ou, mais importante, e o tempo que voce passa trabalhando 
independentemente dos avan^os. 

Se esse e o nucleo da sua vida profissional — o verdadeiro trabalho — entao voce 
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ja chegou ao seu destino. O seu pensamento focado no destino e focado nos objetivos 
apenas o guia de uma meta a outra. Nao existe um fim logico. O que muitos de nos 
nao conseguem entender e que o caminho e o fim. 

De volta ao exemplo do desenvolvimento de software, e facil se envolver demais 
com a entrega do codigo que voce esta criando. Seu cliente precisa de uma aplicaijao 
web, e voce se foca em terminar tal projeto. Mas uma aplica^ao viva nunca esta 
“concluida”. Um lamjamento conduz ao outro. Foco demasiado no produto final nos 
distrai da verdadeira entrega: o desenvolvimento sustentavel de uma nova entidade. 

Concentre-se emfazer, nao no que esta sendofeito. 


Focar no final faz com que voce esque^a de fazer o processo direito. E processos 
ruins criam produtos ruins. O produto deve ter seus requisitos minimos, mas seu 
interior sera feio. Voce se otimizou para a meta a curto prazo — e nao para o futuro 
inevitavel e continuo do desenvolvimento do produto. 

Nao apenas processos ruins fazem produtos ruins, mas produtos ruins fazem 
processos ruins. Uma vez que voce tern um desses produtos que sao bagumjados em 
seu interior, seus processos se adaptam a isso. As janelas quebradas de seu produto 
levam a janelas quebradas em seu processo. E um ciclo vicioso. 

Portanto, em vez de constantemente se perguntar “Ja estamos la? Ja estamos la?” 
perceba que a linica resposta saudavel e “sim”. E como voce cruza o caminho que e 
importante, e nao o destino. 

Fa^a algo 

1) Em seu livro The Miracle of Mindfulness [6], Thich Naht Hanh apresenta uma 
sugestao: a proxima vez que voce tiver que lavar a lou^a, nao o fa$a para te-las 
limpas. Tente apreciar a experiencia de lavar a loucja. Nao se concentre em ter¬ 
minar. Foque-se no ato de lava-las em si. 

Lavar a loui;a e uma tarefa mundana que quase ninguem saboreia. Desenvolve- 
dores de software fazem algo semelhante em um dia normal, como lidar com a 
pressao do tempo e relatorios de gastos, por exemplo. A proxima vez que voce ti¬ 
ver que fazer uma tarefa como essa, veja se ha um jeito de focar na tarefa enquanto 
voce a realiza, em vez de ansiosamente se apressar para conclui-la. 
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Capitulo 47 

Trace um roteiro 


Quando voce esta em “modo manuten^ao”, e facil pegar um ritmo e simplesmente 
continuar a ser como voce e. Como um desenvolvedor de software, voce sabe que 
isso acontece pela sua experiencia com sistemas. Se voce mantem uma aplica^ao ou 
uma biblioteca que outros desenvolvedores usam, ela vai estagnar no modo de cor- 
re^ao de bug (ou pior) ao menos que voce tenha um solido roteiro. Voce pode fazer 
as melhorias ocasionais devido a pedidos dos usuarios ou por necessidade propria, 
mas o codigo eventualmente vai atingir um estado estavel e mudara em uma taxa 
exponencialmente mais lenta, porque voce o considera pronto. 

Contudo, uma aplica^ao viva nunca esta concluida, ao menos que esteja no ca- 
minho para a aposentadoria. O mesmo e valido para sua carreira. A nao ser que voce 
esteja procurando sair do meio, voce precisa de um roteiro. Se a Microsoft tivesse 
considerado o Windows 3.1 pronto, todos nos estariamos usando Macs agora. Se os 
desenvolvedores Apache tivessem considerado seu servidor pronto quando fizeram 
o 1.0, eles nao estariam esmagadoramente liderando o mercado agora. 

O seu roteiro pessoal para seu produto e o que voce usa para dizer se voce pro- 
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grediu ou nao. Quando voce vai para o mesmo escritorio dia apos dia, para trabalhar 
em muitas das mesmas coisas, o cenario ao seu redor nao muda. Voce precisa colocar 
indicadores que voce possa ver a distancia, de modo que possa saber se realmente 
saiu do lugar. As funcionalidades do seu produto sao esses indicadores. 

Ao menos que voce realmente pegue isso e fa^a um piano, voce nao conseguira 
ver alem do proximo pontinho no horizonte. Nos capitulos 2 e 3, voce descobriu 
como escolher o caminho de sua carreira e como investir em sua vida profissional. 
Embora eu tenha focado no que parecia ser uma escolha de uma unica vez sobre 
aquilo em que investir, cada escolha deveria ser parte de algo maior. Pensar em cada 
novo conhecimento ou habilidade como equivalentes a uma simples caracteristica de 
uma aplica^ao traz muito bem esse conceito. Uma aplicaijao com uma caracteristica 
nao e muito uma aplicaijao. 

Alem do mais, uma aplicacjao com um grupo de caracteristicas que nao sejam 
coesas vai confundir seus usuario. Seria isso um caderno de endere^os ou uma 
aplica^ao de chat? E um jogo ou um browser? Um roteiro pessoal para seu pro¬ 
duto pode nao apenas ajuda-lo a seguir seu caminho, constantemente evoluindo, mas 
tambem lhe dar uma visao geral do que voce tern a oferecer. Ele pode mostrar que 
nenhuma caracteristica unica se mantem. Cada novo investimento e parte de um 
todo maior. Algumas funcionam fabulosamente bem juntas, outras requerem um 
grande salto mental para os potenciais empregadores. Seria ele um administrador 
de sistema ou um designer grafico? Seria ela uma arquiteta de aplica^ao ou um 
guru de automa^ao de QA? 

Embora seja definitivamente ok aprender diversas coisas — pois isso expande 
seu pensamento — tambem e uma boa ideia pensar sobre a historia que seu con- 
junto de habilidades conta. Sem um roteiro, sua historia pode parecer mais com um 
romance de Jack Kerouac do que com um coeso grupo de competencias logicamente 
relacionadas. Sem um roteiro, voce pode realmente ate se perder. 

Fa9a algo 

1) Antes de colocar no mapa o lugar para o qual voce quer ir, ele pode ser um roteiro 
informativo e encorajador sobre onde voce esteve. Pegue um tempo para explici- 
tamente escrever a linha do tempo de sua carreira. Mostre onde voce come^ou e 
quais eram suas habilidades e empregos em cada fase. Note os pontos onde voce 
fez melhorias incrementais e onde voce pareceu realizar grandes saltos. Observe 
a duraijao media necessaria para fazer um avan<;o consideravel. Voce pode esta- 
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Capitulo 47. Trace um roteiro 


belecer metas mais objetivas para si se tiver uma imagem clara do historico de se 
progresso. Uma vez que voce criou esse mapa historico, mantenha-o atualizado. 
E uma otima maneira de refletir seu progresso conforme voce move em dire<pao 
ao seus objetivos recem-estabelecidos. 
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Capitulo 48 

Observe o mercado 


Voce seria tolo se investisse seu dinheiro em uma a<;ao volatil e depois ignora-la. 
Mesmo se voce fez muita pesquisa e fez uma escolha proposital sobre em quem in- 
vestir, o mercado e incerto. Voce nao pode simplesmente atirar e se esquecer, quando 
se trata de investimentos. Mesmo se o valor de uma a^ao esta aumentando agora, isso 
nao significa que ele nao vai come^ar a afundar amanha. 

Alem disso, voce pode estar perdendo uma oportunidade. Talvez voce pense 
que seja um porto seguro estar rendendo um retorno de 10% no ano. Isso parece 
realmente um bom negocio, se o resto do mercado nao esta de repente fazendo muito 
melhor que 10%. Seu principal investimento de hoje, mesmo se continuar a agir, pode 
nao ser muito impressionante se comparado com o que sera possivel amanha. 

Na medida em que as condi^oes do mercado mudam, nao prestar aten^ao pode 
resultar em perda de dinheiro ou perda de dinheiro que se poderia ganhar. 

O mesmo e valido para seu investimento em conhecimento. Java e a escolha con- 
servadora dos dias de hoje. O que poderia mudar, que poria em questao tal verdade? 
Como voce poderia saber se isso mudou? 
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E se, por exemplo, a Oracle comeijasse a dar sinais de falencia? No passado, a Sun 
Microsystems, que mantinha o Java, perdeu sua posi^ao dominante, e Java nao era 
um padrao aberto. Embora hoje seja open source, e ditado e desenvolvido pela Ora¬ 
cle. Em qualquer momento, uma moribunda Oracle pode tentar subitamente fazer 
de sua linguagem e de sua maquina virtual um centra lucrativo. Isso pode fragmen- 
tar a linguagem Java com mudan^as incompativeis, gerando um panico enorme. 

Com sua cabe^a focada no codigo do seu monitor, talvez voce nem ou<;a falar 
de algo como isso antes de ser tarde demais. Voce pode se ver no mercado com 
uma habilidade com valor subitamente diminuto. Essa e uma situa^ao hipotetica 
improvavel, mas algo parecido pode acontecer. 

O mais provavel e que, voce estando confortavel em seu emprego atual, com 
suas competencias atuais, voce pode se tornar um ignorante feliz conforme a Nova 
Grande Coisa desponta. Vinte anos atras, voce teria ficado surpreso ao descobrir o 
quao grandes linguagens orientadas a objeto com Gargabe Collection se tornariam. 
Porem, definitivamente havia sinais, se voce os estivesse observando. Daqui a 10 
anos, quern sabe qual sera a nova grande revolu^ao? 

Voce deve manter seus olhos e ouvidos abertos. Observe as novidades tecnolo- 
gicas, tanto pelo vies empresarial como pelo lado tecnico puro, a procura de desco- 
bertas que podem provocar uma onda. Como Tim O’Reilly (http://tim.oreilly.com/) 
, da O’Reilly and Associates, diz, observe os geeks alfa. Os geeks alfa sao aqueles su¬ 
pernerds que estao sempre no mais alto topo do mais alto cume, ao menos em seus 
hobbies. A afirmaijao de Tim, que eu tenho desde entao observado, e que se voce 
consegue achar essas pessoas e ver em que eles estao mergulhados, voce pode ter um 
vislumbre do que potencialmente pode ser grande em um ou dois anos. E estranho 
como isso funciona bem. 

Observe os geeks alfa. 

Independentemente da escolha que voce fizer, e preciso estar atento ao fato de 
que, no setor de tecnologia, o que e um bom investimento hoje eventualmente nao 
sera mais um bom investimento. E, se voce prestar atemjao ao estado de espirito do 
mercado, isso raramente vai pega-lo de surpresa. Voce nao quer esse tipo de surpresa. 

Fa^a algo 

1) Passe o proximo ano tentando se tornar um dos geeks alfa. Ou, ao menos, fa^a o 
gancho com um. 
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Capitulo 49 

Aquele gordo no espelho 


Infelizmente, estou acima do peso. Ja faz tempo. Porem, quando eu morava na India, 
eu perdi muito peso. Parte disso foi por causa da dieta. Parte, pelos exercicios. Mas a 
maior parte foi por ficar doente. Depois que voltei aos Estados Unidos, eu lentamente 
ganhei peso de novo. Era uma coisa desapontadora, a qual reagi me matriculando 
em uma academia e contratando um personal trainer. O peso voltou a diminuir. 

Passei por diversas dessas oscila^oes. O que e fascinante disso tudo e que eu nao 
consigo realmente notar quando estou ganhando ou perdendo peso. A unica forma 
de eu saber e se alguem me disser ou se minhas roupas de repente pararem de caber. 
Minha esposa me ve todo dia, de modo que ela tambem nao consegue notar — e, nos 
Estados Unidos, as pessoas geralmente nao falam nada se voce engordar. Na India, 
sim. 

Eu nao reparo porque me vejo muito frequentemente. Se voce e constantemente 
exposto a algo, e dificil notar que ele esta mudando, ao menos que a mudan^a acon- 
te<;a rapidamente. Se voce sentar e observar uma flor desabrochar, vai passar bastante 
tempo ate que voce note que algo aconteceu. Entretanto, se voce sair e voltar em dois 
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dias, vera algo muito notavel diferente de quando voce saiu. 

Voce percebera o mesmo fenomeno com sua carreira. Na verdade, voce nao 
notara. Este e o problema. Voce pode olhar para si mesmo pelo espelho metaforico 
todo dia e nao ver nenhum tra^o de mudan^a. Voce parece tao bem ajustado quanto 
antes. Voce parece tao competitive quanto antes. Suas habilidades parecem ser tao 
atualizadas quanto antes. 

Entao, de repente, um dia seu emprego (ou seu negocio) nao se encaixa mais 
com voce. Parece apenas desconfortavel no inicio, mas voce ja alcan<pou um ponto 
critico, no qual voce precisa ou agir rapidamente ou comprar um novo par de cal^as 
(metaforicas). 

Quando se trata de flutua^oes de peso corporal, voce tern uma balan^a, entao 
e razoavelmente facil mensurar seu progresso (ou falta dele, no meu caso). Infeliz- 
mente, nao ha balan^a para medir seu poder de marketing ou suas habilidades de 
programador. Se houvesse, poderiamos coloca-la em uma tabela e autogerar seus 
salarios. Ja que isso nao existe, voce tera que criar uma para si mesmo. 

Um jeito facil de medir seu progresso e usar pessoas confiaveis. Um mentor ou 
um colega proximo podem ajudar a dar um olhar mais objetivo sobre onde voce esta. 
Voce pode discutir suas habilidades de desenvolvedor de software, lider de projeto, 
comunicador, membro de equipe, ou qualquer outra faceta do pacote total que o faz 
quern voce e. Na GE, esse e um processo chamado de “revisao 360”, que formaliza 
a ideia e encoraja os funcionarios a procurar por feedback de seus parceiros, seus 
chefes e clientes internos. Esse processo e uma otima forma de obter um numero de 
diferentes perspectivas de si mesmo como um funcionario. 

Desenvolvedor, reveja-te a ti mesmo. 


A coisa mais importante para se trazer a tona, conforme voce passa por um pro¬ 
cesso como este (seja sozinho ou com ajuda), e onde estao seus pontos cegos. Voce 
nao precisa consertar todos eles. Voce apenas deve saber onde eles estao. Sem ser 
especifico, voce sera cego aos seus pontos cegos. E ai que as coisas ruins acontecem e 
o pegam desprevenido. Coisas ruins acontecem, entao e melhor saber que elas estao 
vindo. 

Mesmo se voce tivesse uma balanca magica de valores na qual voce pudesse se 
medir, ela nao lhe faria bem a nao ser que voce realmente a usasse. Agende suas re- 
visoes. Voce nao vai parar para refletir, ao menos que voce torne o tempo de reflexao 
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Capitulo 49. Aquele gordo no espelho 


explicito. Dizer “Nao esquecer de pedir por feedback” nao e uma mensagem sufi- 
cientemente forte. Se voce possui um calendario que tenha lembretes em pop-up, 
marque compromissos consigo mesmo para autoavalia^ao. Primeiro, determine seu 
sistema de medida, e entao, coloque-o na agenda. Se nao for uma parte intrinseca 
de sua vida profissional, voce nao o fara. 

Se sua empresa ja realiza tais processos, nao os trate como algo nonsense de RH. 
Leve-os a serio, e fa^a algo de bom sair disso. Eles podem ter sido implementados 
de um jeito pobre no seu trabalho, mas a motiva^ao (pelo menos o que costumava 
ser motiva^ao) para eles ainda continua de pe. 

Finalmente, quando voce tiver seu proprio sistema, e tiver agendado tempo para 
aplica-lo, guarde os resultados por escrito. Mantenha sua avalia^ao em algum lugar 
proximo. Reveja-o e revise-o com frequencia. Ligar o processo de autoavalia^ao a 
um registro fisico o tornara concreto. 

Nao deixe que coisas antigas o prendam como um par de cal^as apertadas. 

Aja nisso! 

1) Fa^a uma revisao 360. 

• Fa^a uma lista de pessoas confiaveis, com as quais se sente confortavel em 
pedir feedback. Essa lista deve, preferencialmente, conter representantes de 
seus colegas, clientes e chefes (e subordinados, se voce tiver algum). 

• Fa 9 a outra lista de aproximadamente 10 caracteristicas que voce acredita 
que sejam medidas importantes suas como um profissional. 

• Converta essa lista em um questionario. Nele, pe<;a aos participantes para 
lhe darem nota em cada aspecto. Inclua tambem a questao “O que eu devia 
ter perguntado?” 

• Distribua o questionario para uma lista de pessoas de sua confian^a. Pe^a 
aos seus avaliadores que fa^am criticas construtivas. O que voce precisa e 
de feedback honesto — e nao puxa-saquismo. 

2) Depois de receber as respostas, leia-as e compile uma lista de a^oes que voce to- 
mara como resultado. Se voce fez as perguntas certas para as pessoas certas, voce 
tera alguns itens acionaveis. Compartilhe o resultado de seu questionario com 
seus avaliadores — nao as respostas, mas as mudan^as resultantes que voce pla- 
neja fazer. Fembre-se de agradecer. Repita o processo ocasionalmente. 
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3) Comece a manter um diario. Pode ser um blog, como discutimos em 39, ou um 
diario pessoal. Escreva sobre o que voce esta fazendo, o que esta aprendendo e 
suas opinioes sobre o negocio. 

Depois que voce estiver mantendo o diario por algum tempo, releia registros an- 
tigos. Voce ainda concorda? Eles parecem errados? O quanto voce mudou? 
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Capitulo 50 

A armadilha de macaco da India do 
Sul 


Em Zen and the Art of Motorcycle Maintenance [8], Robert Pirsig conta uma historia 
sobre como as pessoas no sul da India costumavam capturar macacos. Eu nao sei se 
isso e verdade, mas nos ensina uma liijao util, portanto vou parafrasea-lo. 

As pessoas na India do Sul, tendo sido importunadas por macacos por varios 
anos, desenvolveram um engenhoso jeito de captura-los. Eles cavavam um buraco 
longo e estreito no chao, e usavam um objeto igualmente longo para alargar o fundo 
do buraco. Entao, jogavam arroz na parte mais larga do fundo. 

Macacos gostam de comer. De fato, essa e uma grande parte do que os torna tais 
pestes. Eles pulam nos carros ou arriscam correr no meio de multidoes para roubar 
comida de suas maos. As pessoas da India do Sul estao dentes disso. (Acredite-me, e 
surpreendentemente perturbador estar sentado, tranquilo, e de repente aparecer um 
macaco safado para roubar algo seu.) 

De acordo com Pirsig, os macacos apareciam, descobriam o arroz e esticavam 
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seus bravos pelo buraco. Suas maos alcan^avam o fundo. Eles pegavam vorazmente o 
maximo de arroz possivel, fechando as maos em punho. Assim fechadas, elas cabiam 
na parte mais larga do buraco, mas o resto da abertura era estreita demais para que 
os macacos puxassem seus punhos cheios de arroz de volta. Eles ficavam presos. 

E claro, eles podiam simplesmente largar a comida e sair livres. 

Mas macacos dao grande valor a comida. Alias, dao tanto valor que nao conse- 
guem se forijar a desistir. Eles vao apertar o arroz ate que ele saia do chao ou morrerao 
tentando tira-lo de la. Este ultimo era o que geralmente acontecia. 

Pirsig conta essa historia para ilustrar um conceito que ele chama de rigidez de 
valor. E o que acontece quando voce acredita tao fortemente no valor de alguma 
coisa que voce nao consegue mais questiona-lo objetivamente. Os macacos valori- 
zavam tanto o aroz que, quando tornados a escolher entre o arroz em cativeiro e a 
morte, nao conseguiam ver que deixar a comida era a coisa certa a se fazer naquele 
momento. A historia faz os macacos parecerem muito estupidos, mas a maioria de 
nos tern nossos proprios equivalentes ao arroz. 

Se lhe perguntassem se e uma boa ideia ajudar a alimentar crian^as famintas em 
paises em desenvolvimento, voce provavelmente diria “sim”, sem pensar. Se alguem 
tentasse argumentar com voce, voce o acharia louco. Este e um exemplo de rigidez 
de valor. Voce acredita nessa coisa tao fortemente que nao consegue imaginar nao 
acreditar nisso. Claramente, nem todos os valores que consideramos rigidos sao 
ruins. Para a maior parte das pessoas, religiao (ou a falta dela) tambem e um conjunto 
de cren<;as pessoais e de valores inabalaveis. 

Porem, nem todos os valores rigidos sao bons. Alem disso, muitas vezes algo que 
e bom em uma determinada circunstancia nao e boa em outra. 

Valores rigidos o tornam fragil. 


Por exemplo, e facil se desligar das escolhas tecnologicas. Especialmente quando 
a tecnologia que escolhemos e underground. Nos amamos tanto tecnologia e colo- 
camos um valor tao alto quando a defendemos para ser adotada, que vemos cada 
oportunidade como uma batalha em que vale a pena lutar — mesmo quando estamos 
defendendo o que claramente e a escolha errada. Um exemplo que encontro (e pelo 
qual provavelmente me sinto culpado) e a base de fas superzelosa de Linux. Muitos 
dos usuarios Linux colocariam Linux no desktop de qualquer recepcionista, assis- 
tente, e vice-presidente da corpora^ao sem levar em considera^ao que, em termos 
de usabilidade, as ferramentas simplesmente nao sao tao compativeis com muitos 
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dos softwares comerciais disponiveis para um sistema operacional comercial. Voce 
fica com cara de bobo e faz seus clientes infelizes quando voce da o software certo 
para as pessoas erradas. 

E dificil perceber que voce esta emagrecendo porque voce se ve todo dia. Rigidez 
de valor funciona do mesmo modo. Desde que vivemos todo dia na mesma carreira, 
e facil desenvolver rigidez de valor em nossas escolhas de carreira. Sabemos o que 
funcionou, e continuamos fazendo isso. Ou, talvez voce sempre quis ser promovido 
a gerencia, entao voce continua se esfor^ando para este objetivo, independente de 
quanto voce gosta de apenas programar. 

Tambem e possivel que a tecnologia de sua escolha se torne obsoleta, deixando- 
lhe subitamente sem uma base na qual se apoiar. Como um sapo em uma panela 
lentamente aquecendo, voce pode de repente se ver em uma situa^ao ruim. Muitos 
de nos, na metade dos anos 90, so pensavamos em Novell NetWare quando se tratava 
de disponibilizar arquivo e imprimir services na empresa atraves de uma rede. A 
Novell estava muito alem de seu tempo com seu produto de services de diretorio, e 
muitos de nos “do conhecimento” eramos quase arrogantes na critica as tecnologias 
concorrentes. O produto da Novell estava desfrutando de uma saudavel lideran^a no 
mercado, e era dificil imaginar a mare mudando. 

Nenhum evento sozinho tornou obvio que a Novell estava perdendo para a Mi¬ 
crosoft. A Microsoft nunca fez o lamjamento magico de um Active Directory, que 
nos fizesse dizer “Uau, ja era NetWare!” Mas a NetWare lentamente foi de inova- 
(jao para tecnologia legada. Para muitos administradores da NetWare, a agua estava 
fervendo antes de eles sequer perceberem que a panela estava morna. 

Se e esse o caminho que sua carreira esta tomando, ou as tecnologias que voce 
defende e nas quais investe, tome cuidado com as armadilhas de macaco. Aquelas 
escolhas originalmente intencionais podem se tornar o ultimo punhado de arroz que 
voce esta segurando antes de sua carreira apanhar ate a morte. 

Fa$a algo 

1) Encontre suas armadilhas de macaco — quais sao suas presumes rigidas? 
Quais sao os valores que guiam suas a (joes diarias sem voce conscientemente sa¬ 
ber? 

Fa<ja uma tabela com duas colunas: “Carreira” e “Tecnologia”. Embaixo de cada 
uma, liste os valores que voce considera como verdades inabalaveis. Por exemplo, 
sob “Carreira”, o que voce sempre considerou como sendo um de seus pontos 
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fortes? Ou fraquezas? Qual e o objetivo de sua carreira (“Eu quero ser CEO!”)? 
Quais sao as maneiras certas de alcan^ar sua meta? 

Na coluna “Tecnologia”, liste o que voce mais valoriza sobre as tecnologias nas 
quais escolheu investir. Quais sao os atributos mais importantes de uma tecno¬ 
logia que deviam ser considerados ao fazer uma escolha? Como voce faz um 
sistema de medida? Qual o ambiente mais produtivo para desenvolvimento de 
software? Quais sao as melhores e piores plataformas, em geral? 

Quando voce tiver sua lista e voce considera-la razoavelmente completa, va item 
por item e mentalmente inverta cada afirma^ao. E se o oposto de cada asser^ao 
fosse verdadeiro? Permita-se honestamente desafiar cada uma. 

Essa e uma lista de suas vulnerabilidades. 

2) Conheca seu inimigo — pegue a tecnologia que voce mais odeia, e fa$a um pro- 
jeto usando-a. Desenvolvedores tendem a separar-se entre os campos concorren- 
tes. As pessoas de .NET odeiam J2EE, e as pessoas de J2EE odeiam .NET. Pessoas 
de UNIX odeiam Windows, e vice-versa. 

Escolha um projeto facil e tente fazer uma otima aplica^ao usando a tecnologia 
que voce odeia. Se voce e uma pessoa de Java, mostre aqueles de .NET como 
um desenvolvedor de verdade usa a plataforma! Na melhor das hipoteses, voce 
aprendera que a tecnologia que voce odeia nao e tao ruim e que, alias, e possivel 
desenvolver bom codigo com ela. Voce tambem tera uma (certamente subde- 
senvolvida) nova habilidade que voce talvez precise usar no futuro. No pior dos 
casos, o exercicio sera uma sessao de pratica para voce, e voce tera mais recursos 
para seus argumentos. 
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Evite planejamento de carreira do 
modelo cascata 


No comedo deste milenio, formou-se uma rebeliao inicialmente pequena na indus- 
tria de software. Um grupo de especialistas em desenvolvimento de software come- 
90U a perceber que, entre eles, estava se formando uma tendencia tanto em projetos 
de software que estavam falindo ou tendo sucesso. Em um ambiente industrial, em 
que mais projetos estao falindo do que tendo exito, eles acreditavam que tinham 
descoberto uma forma de fazer melhor. O grupo se autodenominou Agile Alliance. 

A industria, naquela epoca, se levou a acreditar que o unico jeito de desenvolver 
projetos de software era seguir um processo rigoroso, cautelosamente planejado do 
topo ao fim. Analistas definiam requisitos em longos documentos, enquanto arqui- 
tetos enviavam suas criaijoes para os designers, que criavam designs detalhados. O 
produto disso era passado a desenvolvedores que o transformavam em codigo, em 
alguma linguagem de programa^ao. Finalmente, apos meses — as vezes anos de es- 
forcjo —, o codigo era integrado e entregue a um grupo de teste, que o certificaria 
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para implementa^ao. 

As vezes, alguma variante desse processo funcionava. Se todo mundo soubesse 
cada detalhe necessario no comedo de um projeto, esse tipo de planejamento e rigor 
podia vir a entregar um software bem pensando e com qualidade garantida. Mas 
na maior parte das vezes, as pessoas nao sabem cada detalhe do que eles esperam de 
um grande projeto. Quanto maior e mais complexo for um projeto, e menos provavel 
que seja possivel imaginar cada aspecto com detalhes suficientes para se criar uma 
especifica^ao. Esse tipo de processo e um processo em cascata, e essa expressao e 
equivalente a processos ruins praticamente de forma universal nos dias de hoje. 

Entao, como os membros da Agile Alliance perceberam, seguir um processo ri- 
gido como a maioria das organiza^oes estava fazendo na epoca, resultava em soft¬ 
ware bem testado e minuciosamente documentado, o que nao era o que os usuarios 
queriam. A rebeliao foi criar uma familia de metodologias ageis. Eram processos 
de desenvolvimento de software que caminhavam em dire^ao a mudan^a facil. Me¬ 
nos tempo era gasto fazendo o planejamento e o design. Software e maleavel, entao 
muda-lo pode ser barato. As metodologias ageis pressupunham as mudan^as como 
uma parte constante do desenvolvimento, e adaptavam-se para torna-las o mais ba¬ 
rato e facil possivel. 

Tudo isso parece obvio agora. Mas naquela epoca, a ado<;ao de processos ageis 
era um motivo de conflito e debate. Em tese, a ideia de planejar com detalhe e rigor 
parece obviamente correta. Mas na pratica, isso nao funciona. 

No initio da minha propria conversao as metodologias ageis (especialmente Ex¬ 
treme Programming), passei a ver tudo atraves das lentes do desenvolvimento agil. 
As formas e as motivates em jogo vieram a ser mais gerais do que para apenas desen¬ 
volvimento de software. Toda vez que eu tinha que resolver um problema complexo, 
eu percebia que uma abordagem iterativa e receptiva a mudan^as era um jeito menos 
estressante e mais efetivo para mim. 

De alguma forma, contudo, levou-me bastante tempo para perceber que o pro¬ 
jeto mais complexo com que ja tive de lidar — o mais estressante e mais critico — era 
minha carreira. Eu tinha projetado minha carreira do comedo ao fim como um pro¬ 
jeto de software com modelo em cascata. E os mesmos problemas que ocorriam em 
projetos de software estavam come^ando a acontecer comigo e com minha carreira. 

Eu estava na trilha para ser um vice-presidente bem sucedido, ou um diretor 
de informatica. Estava indo muito bem nesse caminho. Eu havia progredido rapi- 
damente de um programador novato para um arquiteto de software, ate gerente e 
diretor, e podia facilmente me ver continuando na cadeia. Mas, por mais bem suce- 
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dido que eu fosse, comecei a sentir que estava fazendo um trabalho de que eu nao 
gostava. De fato, quanto mais bem sucedido que eu era, era menos provavel que eu 
estivesse em um emprego de que gostasse. 

O que eu estava fazendo comigo era a mesma coisa que processos rigido fa- 
zia com seus clientes. Eu estava fazendo um trabalho excelente de entregar a mim 
mesmo uma carreira que eu nao queria. 

Nao era intuitivo para mim no comedo, mas a solu^ao para tal problema era 
simplesmente mudar de carreira. Isso pode ter varios significados. Para mim, signi- 
ficava voltar a tecnologia crua que me deixara tao excitado com a industria de TI em 
primeira instancia. Para outras pessoas, o significado foi mudar de administra^ao de 
sistema para desenvolvimento de software, ou mudar de um campo nao relacionado 
a computa^ao para programa^ao, ou mesmo largar toda a profissao e fazer qualquer 
outra coisa que ama. 

Assim como em desenvolvimento de software, o custo da mudan^a nao precisa 
ser alto. E claro, pode ser dificil mudar de testador de software para advocacia. Mas 
mudar seu caminho de gerencia para programa^ao, ou vice-versa, nao e dificil. Tam- 
pouco e encontrar uma nova empresa para a qual trabalhar. Ou mudar de cidade. 

E ao contrario de, digamos, construir um arranha-ceu, mudar sua carreira nao 
requer que voce jogue fora tudo que voce ja fez. Eu fiquei programando em Ruby ate 
agora, mas minha experiencia como gerente, ou a cria^ao de uma opera^ao de de¬ 
senvolvimento offshore, sao constantemente relevantes e prestativas no que eu fa 90. 
Meus empregadores e clientes entendem isso e tiram proveito. 

E importante perceber que mudan^as nao sao apenas possiveis em sua carreira, 
como sao necessarias. Como um desenvolvedor de software, voce nunca gostaria 
de desenvolver algo que seu cliente nao quer. Metodologias ageis ajudam a prevenir 
isso. O mesmo e valido para sua carreira. Determine grande objetivos, mas fa 9 a 
corre^oes constantes ao longo do caminho. Aprenda com a experiencia, e modifique 
as metas conforme voce avan^a. Em ultima instancia, um cliente feliz e o que todos 
queremos (especialmente quando, na medida em que planejamos nossas carreiras, 
somos os nossos proprios clientes) — nao um requerimento completo. 
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Consertar um erro e (geralmente) facil. Algo esta quebrado, porque alguem relatou. 
Se voce consegue reproduzir o erro, entao consertar um erro significa corrigir qual- 
quer mau funcionamento que o causou e verificar que ele nao e mais reproduzlvel. 
Se ao menos todos os problemas fossem tao simples! 

Mas nem todo problema ou desafio e tao discreto. A maioria dos desafios im- 
portantes na vida se manifestam como grandes e intransponiveis gotas amorfas de 
fracasso em potencial. Isso e verdade em desenvolvimento de software, gerencia- 
mento de carreira, e ate estilo de vida e saude. 

Um sistema complexo e cheio de erros precisa ser revisto. Sua carreira esta es- 
tagnando a cada minuto. Voce esta passivamente deixando que seu estilo de vida 
de programador sedentario baseado em uma escrivaninha transforme seu corpo em 
uma desordem. Todos esses problemas sao muito maiores e mais dificeis de serem 
simplesmente consertados do que um bug. Eles sao complexos, dificeis de medir, e 
compostos de multiplas solu^oes pequenas e diferentes, algumas das quais vao fra- 
cassar! 
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Devido a essa complexidade, nos facilmente nos desmotivamos para as grandes 
questoes e, em vez disso, viramos nossa atemjao a coisas que sao mais faceis de se 
medir e mais rapidas de se consertar. Eis porque procrastinamos. E procrastinate 
gera culpa, o que faz com que nos sintamos mal e, portanto, procrastinemos um 
pouco mais. 

Como eu mencionei em 49, eu tenho lutado para me manter em forma desde 
que me posso me lembrar. De fato, quando voce esta miseravelmente fora de forma, 
“Simplesmente entre em forma” nao e um conceito que voce pode sequer compre- 
ender, muito menos fazer algo concreto a respeito disso. Para dificultar, se voce fi- 
zer algo para melhora-lo, voce nao vai conseguir notar imediatamente, ou mesmo 
passada uma semana, que algo mudou. Alias, pode ser que voce passe todo o dia 
treinando para entrar em forma, e uma semana depois voce nao tenha mais nada a 
oferecer. 

Esse e o tipo de desmotivador que pode pular na sua frente e o derrotar antes 
mesmo de voce come^ar. 

Eu tenho trabalhado seriamente nesse problema. Ir a academia quase diaria- 
mente, alimentar-me melhor. Mas mesmo quando estou levando o programa a serio, 
e dificil ver os resultados. 

Enquanto eu estava chafurdado em minha desmotiva^ao uma tarde dessas, meu 
amigo Erik Kastner postou uma mensagem no Twitter, com o seguinte texto: 

Ajude-me a entrar em forma... pergunte-me uma vezpor dia: “Hojefoi melhor que 
ontem?” (nutri^ao / exercicio) - hoje: SIM! 

Quando li isso, percebi que esse era o ingresso para entrar em forma. Eu o reco- 
nheci dos grandes problemas que eu resolvi com sucesso em minha vida. O segredo 
e focar em fazer o que quer que voce esteja tentando hear melhor hoje do que era on¬ 
tem. E isso. fi facil. E, assim como Erik estava, e possivel sentir entusiasmo quando 
se da passos reais e tangiveis em direijao a uma meta distante. 

Eu tambem estive recentemente trabalhando em uma das aplica^oes Ruby on 
Rails mais complexas e feias que ja vi. Minha empresa a herdou de outro desen - 
volvedor como um projeto de consultoria. Havia poucas caracteristicas chave que 
precisavam ser implementadas e uma enorme quantidade de bugs e questoes de per¬ 
formance para serem corrigidas. Quando abrimos o capo para realizar essas mu- 
damjas, descobrimos uma gigantesca bagun^a. A empresa estava com restriijoes de 
tempo e dinheiro, entao nao tinhamos o luxo de come^ar do zero, mesmo que aquilo 
sendo o classico tipo de codigo que te da vontade de jogar fora. 

Portanto, fizemos pequenas corre^oes apos pequenas corre<;6es, levando muito 
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mais tempo para terminar cada uma do que era esperado. Quando come^amos, pare- 
cia que a monstruosidade da base do codigo nunca ia se dissipar. Trabalhar naquela 
aplica^ao era cansativo e chato. Mas com o tempo, as corre^oes se tornaram mais 
rapidas, e a performance antes inaceitavel da aplica^ao havia melhorado. Isso acon- 
teceu porque nos tomamos a decisao de tornar a base do codigo cada dia melhor do 
que era no dia anterior. Algumas vezes, isso significava refatorar um longo metodo 
em varios menores e mais organizados. As vezes, significava remover hierarquias de 
heran^a que nunca pertenceram ao modelo de objetos. Outras vezes, simplesmente 
significava consertar um teste de unidade bastante quebrado. 

Porem, desde que fizemos essas mudan^as de forma incremental, elas vieram “de 
gracja”. Refatorar um metodo e algo que voce poderia fazer enquanto voce estava to- 
mando uma xicara de cafe ou conversando com um colega sobre as ultimas noticias. 
E fazer uma pequena melhoria e motivador. Voce pode claramente ver a diferen^a 
nessa pequena coisa que voce consertou, tao logo quanto a mudan^a foi feita. 

Mas talvez voce nao consiga ver uma diferen^a notavel no total com cada mu- 
dam;a incremental. Quando voce esta tentando se tornar mais respeitado em seu 
lugar de trabalho, ou ser mais saudavel, as melhorias individuals que voce realiza 
cada dia frequentemente nao apontam diretamente para resultados tangiveis. Essa 
e, como vimos antes, a razao pela qual grandes metas como essas se tornam tao des- 
motivantes. Portanto, para a maioria dos objetivos grandes e diffceis pelos quais voce 
esta lutando, e importante pensar nao tanto em se aproximar a meta cada dia, mas 
sim pensar em sair-se melhor em seus esfor<pos do que ontem. Eu nao posso, por 
exemplo, garantir que serei menos gordo hoje do que ontem, mas eu posso contro- 
lar se eu estou fazendo mais hoje para perder peso. E se eu o fizer, tenho o direito de 
me sentir bem com o que fiz. Essas melhorias consistentes e mensuraveis em minhas 
a^bes me liberta do ciclo de culpa e procrastinate que geralmente derrota muitos 
de nos quando tentamos fazer as Coisas Mais Importantes. 

Voce tambem precisa se sentir feliz com pequenas quantidades de “melhor”. Es- 
crever um teste a mais do que voce fez ontem e suficiente para aproxima-lo mais 
ao objetivo de “ser melhor em teste de unidade”. Se voce esta come^ando do zero, 
um teste adicional por dia e uma taxa sustentavel, e quando chegar o momento em 
que voce nao consegue mais fazer melhor que ontem, voce descobrira que voce ja se 
tornou “melhor em teste de unidade” e que nao precisa mais continuar fazendo as 
mesmas melhorias. Se, por outro lado, voce decidiu partir do zero em dire^ao a 50 
testes no primeiro dia de seu piano, o primeiro dia sera dificil e o segundo provavel- 
mente nao acontecera. Portanto, fa<;a suas melhorias pequenas e incrementais, mas, 
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sobretudo, diariamente. Pequenas mudan^as tambem diminuem o pre^o da falha. 
Se voce perder um dia, voce tera uma nova base para amanha. 

Uma das melhores coisas sobre essa simples maxima e que voce pode aplica-la 
para metas muito taticas, tais como terminar um projeto ou melhorar um trecho do 
programa. 

Como voce agiu melhor hoje para melhorar sua carreira do que voce fez ontem? 
Fa<;a mais um contato, submeta um patch a um projeto open source, escreva um 
post bem pensado e o publique em seu blog. Ajude mais uma pessoa em um forum 
tecnico de sua area, do que voce fez ontem. Se todo dia voce fizer algo um pouco 
melhor do que ontem para melhorar a si mesmo, voce descobrira que o que era uma 
distancia oceanica para construir uma carreira notavel se tornou mais palpavel. 

Fa$a algo 

1) Fa<;a uma lista de melhorias complexas e dificeis que voce gostaria de realizar; 
podem ser tanto de ambito pessoal como profissional. Esta tudo bem se voce tern 
uma lista razoavelmente longa. Agora, para cada item da lista, pense sobre o que 
voce poderia fazer hoje para melhorar ou fazer aquele item melhor que ontem. 
Amanha, olhe para a lista de novo. Ontem foi melhor do que o dia anterior? 
Como voce pode fazer hoje melhor? Fa^a o mesmo no proximo dia. Coloque 
isso em seu calendario. Use dois minutos pensando sobre isso cada manha. 
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Em momentos de estresse, eu geralmente olho para os meus dias em uma grande em- 
presa. Eu estava tao encaixadinho no meu proprio escritorio, ou cubiculo, e em uma 
espessa e macia camada da hierarquia de gerencia. Era uma piada para nos ali, mas 
em uma grande empresa, uma pessoa esperta pode permanece sem necessariamente 
conduir nada. Na maioria dos casos, se um projeto nao se tornar pronto, havia gente 
sufkiente dividindo a culpa em camadas suficientes, sendo dificil descobrir onde as 
coisas deram errado. E isso e apenas para as falhas. Se as coisas demorassem mais 
do que deveriam, a complexidade da organiza^ao obscurecia as razoes a um ponto 
em que ninguem realmente tinha a no^ao de quanto tempo qualquer projeto deveria 
levar para hear pronto. 

Entao, em um dia em que voce nao esta disposto a realmente pisar no acelerador, 
uma grande empresa lhe concede a oportunidade de sentar-se e, digamos, navegar 
na internet por um tempo. Ou ir para casa mais cedo. Ou tirar um dia de licen^a. 
Apesar de todas as reclama^oes que fiz durante minha vida sobre empresas grandes, 
definitivamente havia suas vantagens. 
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O problema e que o manto de seguraruja de uma hierarquia corporativa diminui 
sua velocidade. Se voce consegue se esconder por tras do escudo da mediocridade 
que a maioria das divisoes corporativas impunham, nao ha muito incentivo para 
exceder. Mesmo aqueles de nos que sao geralmente bem intencionados sao tentados 
pelo oasis paradisiaco do Youtube ou sua coleijao favorita de web comics. Se voce 
estiver procurando por um, tente http://toothpastefordinner.com. Ri durante horas. 

Nesse sentido, uma grande empresa se torna um lugar maravilhoso para ir e 
semi-aposentar-se se voce esta cansado. Mas se voce esta lutando para ser nota- 
vel (o que voce esta!), uma grande empresa e um lugar dificil para entrar no ritmo 
certo, do mesmo jeito que uma padaria e um lugar ruim para tentar eliminar seus 
pneuzinhos. 

A soluijao? Seja independente! 

Voce possui um conjunto de habilidades. Voce as afiou. Voce sabe o que voce 
vale. Tornar-se um alguem independente e um dos testes derradeiros. Voce nao 
tern burocracia por tras da qual se esconder. Voce e diretamente encarregado das 
pessoas pagando as contas. A ideia de que voce esta fornecendo um servi<;o se torna 
diretamente aparente em tudo o que voce faz. Nao ha equipe com quern dividir a 
culpa quando voce faz coisas erradas. E somente voce, seus conhecimentos e sua 
habilidade de executar. 

Tornar-se independente tambem o forqa a aprender como fazer marketing de 
si mesmo e, ao mesmo tempo, testar suas escolhas de dominio e tecnologia em que 
focar. Voce nao pode depender de ser encontrado pelos clientes quando voce se torna 
independente, no sentido como era em uma grande empresa, quando o trabalho o 
encontrava. Voce precisa sair e encontrar seus clientes. Uma vez que voce os achou, 
voce precisa convence-los de que voce e digno de seu pagamento. 

Voce tambem precisa decidir quanto voce quer cobrar. O que voce faz custa 50 
por hora? Ou custa 250? 

Como voce ira pagar suas contas? Como voce justificara a quantia que voce vale? 
Voce realmente vale o tanto que voce achava que valia? 

Ser independente e dificil. Coloca todas suas habilidades enquanto profissional 
em teste. Voce talvez nao esteja pronto para isso ainda. A boa noticia e que voce 
nao precisa percorrer o caminho inteiro. Considere isso como um projeto de desen- 
volvimento pessoal, e coloque-se no mercado em seu tempo livre. Determine uma 
meta de ser contratado e conclua-a com um cliente satisfeito. Trabalhe nisso a noite 
e aos finais de semana (mas por favor, nao trabalhe em seu cubiculo, em seu trabalho 
fixo!). Voce aprendera muita coisa sem perder sua rede de seguramja. Na pior das hi- 
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Capitulo 53. Seja independente 


poteses, voce trabalhara demais por algumas semanas, falhara em um projeto, e sera 
mandado de volta para sua confortavel cadeira com uma nova sensa^ao de apreciar 
seu emprego. No melhor dos casos, voce sera amplamente bem sucedido, amara o 
trabalho, e se colocara em um novo caminho em dire^ao a uma satisfatoria carreira 
e a recompensa financeira. 

O revisor Sammy Larbi sugere outra alternativa para ser independente. Se voce 
atualmente trabalha para uma grande empresa, considere juntar-se a uma pequena. 
Se voce trabalha para uma empresa consagrada, tente uma startup. Em uma pequena 
startup, voce pode tirar o melhor dos dois mundos: um emprego de tempo integral 
com um salario e o desafio de ser colocado contra os problemas de seu negocio, sem 
filtro. 

Curiosidade e um ponto forte 

por Mike Clark 

Meus pais falariam que eu era uma crian^a curiosa. Fazia varias perguntas, lia 
tudo que eu tinha em maos, e aprendia como as coisas funcionam desmontando-as. 
Como se ve, isso nao foi apenas uma fase — eu nunca deixei de ter uma curiosidade 
insaciavel. E facil negligenciar, mas acredito que curiosidade pode ser um ponto 
forte. As vezes, so e necessario um pouco de pratica para desenvolve-la. 

Olhando para tras, consigo identificar varios eventos que mudaram minha car¬ 
reira, que ocorreram principalmente porque eu segui uma curiosidade. Aqui oteredo 
os seguintes exemplos, na esperan^a de que eles o encoragem a escutar quando a cu¬ 
riosidade chama: 

Eu nunca descobri que viraria um programador. Sempre fui fascinado por avioes 
e naves espaciais, entao entrar para o programa de engenharia espacial da Embry- 
Riddle Aeronautical University parecia a escolha logica. Depois de um ano olhando 
por ai, entretanto, descobri que a galera do departamento de Ciencia da Computa- 
$ao estava se divertindo muito mais. Como parte do novo programa de gradua^ao, 
eles estavam aplicando ciencia da computa^ao em problemas relacionados a avia^ao. 
No ensino medio eu havia me tornado curioso sobre computadores, mas nunca re- 
almente tinha considerado programa^ao como uma carreira. Entao, comecei a sair 
com os geeks da computa^ao para ver o que eles faziam. Em pouco tempo, eu troquei 
os programas de gradua^ao. Essa mudan^a por si so acabou sendo uma das minhas 
melhores decisoes. Os cursos ainda eram desafiadores, mas eu amava cada minuto. 
Minha curiosidade inicial em programacyio rapidamente se tornou uma paixao que 
me fez me inscrever em um estagio da NASA e come^ar minha carreira em software 
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com um grande salto. E ate o dia de hoje, eu nunca subestimo a recompensa em po¬ 
tential de descobrir em que os companheiros geeks estao trabalhando por diversao. 

Toda vez que me sinto confortavel, sei que e hora de tentar algo novo. Apos mui- 
tos anos escrevendo software embarcado na industria aeroespacial, eu estava confor¬ 
tavel (o que, para mim, sempre esta associado a tedio) com C e C++. Naquela epoca, 
programa^ao web acordou minha curiosidade, principalmente porque era radical- 
mente diferente de programa^ao de sistemas embarcados. Infelizmente, o projeto do 
meu emprego nao tinha acesso a web (era um daqueles projetos ultrasecretos), entao, 
resolvi passar minhas noites e finais de semana aprendendo a escrever software para 
web. Esse interesse lateral eventualmente se tornou uma oportunidade de trabalhar 
em um novo projeto, usando Java. Acabei construindo aplica^oes web baseadas em 
Java para muitos mais projetos... e empregadores. Minha curiosidade sobre desen- 
volvimento web era o catalisador para diversificar minhas habilidades, o que acabou 
sendo uma boa mudan^a de carreira. 

Eu aprendi Ruby on Rails por um capricho. Ruby era uma linguagem divertida 
que me fazia pensar diferente sobre programa^ao. Rails fazia o mesmo para as apli- 
ca^oes web. Eu nao tinha nenhum cliente naquela epoca que estava contratando tra- 
balho em Ruby on Rails, mas isso nao importava. Eu era curioso, e simplesmente nao 
conseguia evitar. Eu peguei as horas menos uteis e usei para me dedicar ao Ruby on 
Rails. Mai sabia eu que no comedo de 2005 eu receberia a oportunidade de construir 
uma das primeiras aplica^oes comerciais Rails e seria convidado po Dave Thomas 
para ajuda-lo em seu livro de Rails. Minha curiosidade sobre outra nova tecnologia 
come^ou outra curva de sucesso em minha carreira. 

Minha curiosidade vai alem da tecnologia; aspectos de negocio sao igualmente 
interessantes para mim. Isso me levou a me aventurar por conta propria como um 
consultor independente e a come^ar uma empresa de treinamento (The Pragmatic 
Studio). Minha curiosidade no funcionamento de uma pequena empresa me deu 
a oportunidade de aprender um monte de novas habilidades: vendas, marketing, 
suporte ao cliente e assim por diante. Ver o grande cenario me ajudou a me tornar 
um programador melhor. 

Entao, onde esta sua verdadeira curiosidade? Tente seguir seus interesses por 
um tempo, e veja o que acontece. Voce pode se surpreender! 

Mike Clark e um programador/consultor independente 
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Divirta-se 


Mas eu vos digo que, quando trabalhais, realizaisparte do sonho mais longinquo da 
terra, desempenhando assim uma missao que vosfoi designada quando esse sonho 
nasceu. E, apegando-vos ao trabalho, estareis na verdade amando a vida. E quern 
ama a vida atraves do trabalho, partilha do segredo mais intimo da vida. 

- Kalil Gibran, O profeta 

Se voce alcan^ou o ponto de ser um desenvolvedor de software com o luxo de 
realmente pensar sobre qual caminho voce quer que sua carreira tome, parabens! 
Voce pode se considerar bastante sortudo. Existem muitas culturas nas quais poder 
decidir o que voce faz como profissao e um enorme privilegio que poucas pessoas 
disfrutam. Como um programador, e provavel que voce nao precise se preocupar 
em como pagar por um lugar para viver ou como comprar comida. 

Voce poderia ter escolhido dentre inumeras carreiras, mas esta e excitante. E 
criativa. Requer pensamento profundo e lhe traz como recompensa a sensa^ao de 
conseguir fazer algo que a maioria das pessoas que voce encontra todo dia nao ima- 
gina que seja possivel. Nos nos preocupamos com progredir para o proximo nivel, 
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causar um impacto, ou ganhar respeito dos nossos colegas na industria, mas se voce 
realmente parar para pensar nisso, nos nos saimos muito bem. 

Desenvolvimento de software e tanto desafiador como recompensador. E cria- 
tivo como uma forma de arte, mas (diferentemente da arte) fornece valor concreto e 
mensuravel. 

Desenvolvimento de software e divertido! 

Por fim, a coisa mais importante que eu aprendi nessa jornada que minha car- 
reira em programa^ao tern sido e que nao e o que voce faz como profissao, ou o que 
voce tem, que importa. E como voce escolhe aceitar essas coisas. E interno. Satisfa- 
^ao, como nossa escolha de carreira, e algo que devia ser buscado depois e decidido 
intencionalmente. 
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Nota da editora 


A tradu^ao deste livro foi feita por Adriano Almeida e Vivian Matsui. Em caso de du- 
vidas ou sugestoes, voce pode entrar em contato com os editores atraves dos e-mails 
adriano.almeida@casadocodigo.com.br e vivian.matsui@casadocodigo.com.br. 
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